lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.64.0607201856320.2652@p34.internal.lan>
Date:	Thu, 20 Jul 2006 18:57:11 -0400 (EDT)
From:	Justin Piszcz <jpiszcz@...idpixels.com>
To:	Nathan Scott <nathans@....com>
cc:	Chris Wedgwood <cw@...f.org>, David Greaves <david@...eaves.com>,
	Kasper Sandberg <lkml@...anurb.dk>,
	Torsten Landschoff <torsten@...ian.org>,
	linux-kernel@...r.kernel.org, xfs@....sgi.com, ml@...og.se,
	radsaq@...il.com
Subject: Re: FAQ updated (was Re: XFS breakage...)

Erm, the xfs_repair -n only prints out what it needs to fix, I read 
somewhere that xfs_repair may make things worse?

What is the 'correct' fix?

On Thu, 20 Jul 2006, Justin Piszcz wrote:

> Nasty!
>
>        - agno = 37
> No modify flag set, skipping phase 5
> Phase 6 - check inode connectivity...
>        - traversing filesystem starting at / ...
> free block 16777216 for directory inode 2684356622 bad nused
> free block 16777216 for directory inode 2147485710 bad nused
>        - traversal finished ...
>        - traversing all unattached subtrees ...
>        - traversals finished ...
>        - moving disconnected inodes to lost+found ...
> Phase 7 - verify link counts...
> No modify flag set, skipping filesystem flush and exiting.
> p34:~#
>
> I applied the "one line fix" - I should be ok now?
>
>
>
> On Fri, 21 Jul 2006, Nathan Scott wrote:
>
>> On Thu, Jul 20, 2006 at 06:43:34PM -0400, Justin Piszcz wrote:
>>> p34:~# xfs_check -v /dev/md3
>>> xfs_check: out of memory
>>> p34:~#
>>> 
>>> D'oh...
>> 
>> xfs_repair -n is another option, it has a cheaper (memory wise,
>> usually) checking algorithm.
>> 
>>> As long as it mounted ok with the patched kernel, should one be ok?
>> 
>> Not necessarily, no - mount will only read the root inode.
>> 
>> cheers.
>> 
>> -- 
>> Nathan
>> -
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majordomo@...r.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at  http://www.tux.org/lkml/
>> 
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ