Re: FAQ updated (was Re: XFS breakage...)

[Justin Piszcz <jpiszcz@lucidpixels.com>]

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@vger.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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/