[Top] [All Lists]

Re: xfs_repair unable to repair a corrupt filesystem

To: "Russell G. Howe" <rhowe@xxxxxxxxxx>
Subject: Re: xfs_repair unable to repair a corrupt filesystem
From: Nathan Scott <nathans@xxxxxxx>
Date: Mon, 24 Feb 2003 08:59:31 +1100
Cc: linux-xfs@xxxxxxxxxxx
In-reply-to: <20030223081255.GA14077@xxxxxxxxxxxxxxxxxxxxx>
References: <20030223081255.GA14077@xxxxxxxxxxxxxxxxxxxxx>
Sender: linux-xfs-bounce@xxxxxxxxxxx
User-agent: Mutt/1.5.3i
On Sun, Feb 23, 2003 at 08:12:55AM +0000, Russell G. Howe wrote:
> Hi,
> I'm having some problems with /var on my machine. The machine itself is
> rather unstable and hangs every few days, but I don't think that is
> XFS-related.
> ...
> I'm using XFS from CVS, sometime around the 19th Dec (that is the date
> of compilation, and I update just before I compile). It's based on

There was an XFS problem in syncing when remounting read-only
(which happens just before reboot), which was fixed earlier this
year - it frequently affected /var because that is always very
active during shutdown - this fix might help you if you upgrade.

> xfs_repair on /var appeared to fix at least some things, but there were
> clearly still errors. I re-ran xfs_repair and got this output:
> http://rhowe.sfarc.net/xfs_repair_var.txt.gz

correcting nblocks for inode 2222, was 0 - counted 189764
correcting nblocks for inode 6296608, was 0 - counted 189764
Phase 7 - verify and correct link counts...
corrupt dinode 2222, extent total = 2, nblocks = 0.  Unmount and run 
xfs_repair.fatal error -- couldn't map inode 2222, err = 990

Basically, the reason you're getting this error is because
somehow those two earlier statements (correcting nblocks)
have become undone, somehow, by a later stage of repair;
when phase7 comes along and expects this to be fixed, it
ain't, so it coughs up a lung.

Inodes 2222 and 6296608 are two unhappy looking files - 
can you send me the output of:

# xfs_db -c 'inode 2222' -c p /dev/XXX

You may find that forcing the nblocks value to be 189764
for these inodes gets xfs_repair past this hurdle (I can't
see how it is getting "unfixed" though - some experiments
on my machine suggest xfs_repair handles this case as I
would expect).  To force the block count for these inodes,
do something like (fs must be unmounted):

# xfs_db -x -c 'inode 2222' -c 'write core.nblocks 189764' /dev/XXX
(repeat for inode 6296608)

and then run repair again, to see if that's helped at all.



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