hi,
On Wed, Jan 16, 2002 at 11:37:58PM -0500, Nathan J. Mehl wrote:
> In the immortal words of Nathan Scott (nathans@xxxxxxx):
> > >
> > > Is there anything that can be done manually to avoid this, or should I
> > > just let xfs_repair do its job and salvage what I can from lost+found?
> >
> > That's pretty much the only option available at this point
> > (unless you've used xfsdump/some other backup utility to keep
> > a recent backup, and can use that in conjunction/instead).
>
> Hm. Okay, I seem to have run into another xfs_repair issue. The cvs
> code pushes past the log error, but there are a number of inodes that
> it seems unable to properly clear/repair. Every run of xfs_repair on
> this fs since the first one produces the following output:
>
> http://blank.org/memory/repair.out
>
ugh, that looks nasty - inode 448 seems to be a recuring theme.
can you send me output from:
# xfs_db -r -c 'inode 448' -c p /dev/XXX
[at a guess I'd say 448 is a directory inode, something in repair
thinks its free, and some other part of repair doesn't, and all the
other inodes are direct children of 448]
it would also help greatly if I could get access to the filesystem,
eg. by ssh or by downloading the compressed image (probably way too
big in your case by the look of it).
cheers.
> Subsequent iterations produce exactly the same output, referencing
> exactly the same inodes.
>
> Any notion why xfs_repair might be claiming to move directories and
> files into lost+found but not actually doing it?
>
> -n
>
> -----------------------------------------------------------<memory@xxxxxxxxx>
> "`G.I. Jane' is a demeaning, violent, bloody workout video. Some brief
> nudity, bad language and a false sense of human resilience. Rated R." (--CNN)
> <http://blank.org/memory/>---------------------------------------------------
--
Nathan
|