xfs
[Top] [All Lists]

Re: RE: xfs_repair leaves things un-repaired.

To: Barry Naujok <bnaujok@xxxxxxxxxxxxxxxxx>, xfs@xxxxxxxxxxx
Subject: Re: RE: xfs_repair leaves things un-repaired.
From: Andrew Jones <ajones@xxxxxxxxxxxxx>
Date: Tue, 30 Jan 2007 08:45:51 -0500
In-reply-to: <200701300010.LAA00558@larry.melbourne.sgi.com>
References: <200701300010.LAA00558@larry.melbourne.sgi.com>
Sender: xfs-bounce@xxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.13) Gecko/20060809 Debian/1.7.13-0.3
Barry Naujok wrote:

Hi Andrew,

The xfs_repair output is valid. All the inodes that are reporting errors
are orphaned inodes that were moved into lost+found. At the start of
phase 4, the lost+found directory is deleted which causes all the inodes
in lost+found to be re-orphaned. The current solution to this problem is
to rename lost+found after an xfs_repair run and then unmount and try
xfs_repair again.

Regarding the shutdown, that is not normal and I personally don't know
what the problem is from the trace. If it's a corrupt lost+found that
xfs_repair is generating (I gather you are rm'ing lost+found), the
second xfs_repair run after a rename should identify the problem with
the directory. You can also try running xfs_check on the device as it
may pick up something xfs_repair is missing.

Regards,
Barry.


Thanks a lot for the clear explanation. I still don't know why it bombs out and shuts down the filesystem when the corrupt directories are manipulated, but I don't particularly care, in this case. Moving lost+found and re-running xfs_repair has worked out the problem. I can now manipulate the contents of lost+found safely.


<Prev in Thread] Current Thread [Next in Thread>