On Sun, Feb 23, 2003 at 08:12:55AM +0000, Russell G. Howe wrote:
> 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
> 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:
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.