On Mon, Feb 24, 2003 at 08:59:31AM +1100, Nathan Scott wrote:
> 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.
Hm, I didn't realise all filesystems were remounted ro, I thought all
but / were unmounted and then only / was remounted ro. Oh well you learn
something new every day!
> > 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
> 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
> 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)
I'm assuming doing this will alter the structure of the inode, as seen
in the previous URL so I'll hold off running this in case you spot
something in the output above.
I don't need the file referenced by inode 2222, so losing it is of no
consequence. I'd actually forgotten about its existence!
Russell Howe | Why be just another cog in the machine,
rhowe@xxxxxxxxxx | when you can be the spanner in the works?