On Mon, Feb 24, 2003 at 03:33:09AM +0000, Russell G. Howe wrote:
> 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!
No, you were right - I should have read your original mail
more carefully.
> > > 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
> >
> > [snip]
> >
> > 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
>
> See http://rhowe.sfarc.net/xfs_db_inode_2222.txt
Thanks. Its as it seemed & repair is saying - the inode has
an incorrect nblocks field for some reason. I will have to do
some more experiments with repair on a file like this (i.e.
this large, and split into two extents like this), my previous
little experiment where repair worked was on a small file.
> > 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
Yep.
> in the previous URL so I'll hold off running this in case you spot
> something in the output above.
Go ahead and try the write - I'll try creating an inode like yours
locally, and running repair over it.
> I don't need the file referenced by inode 2222, so losing it is of no
> consequence. I'd actually forgotten about its existence!
Is inode 6296608 a copy of this file? (seem to have the same size
and both seem to be corrupted in the same way ...strange).
cheers.
--
Nathan
|