Am Fr 01.04.2005 03:44 schrieb Nathan Scott <nathans@xxxxxxx>:
> On Thu, Mar 31, 2005 at 09:35:29AM +0200, Sven Gehr wrote:
> > Am Do 31.03.2005 01:55 schrieb Nathan Scott <nathans@xxxxxxx>:
> > > You can dump the inode by pointing xfs_db at the device:
> > > # xfs_db -r -c 'inode 134762498' -c 'print' /dev/mdXXX
> > core.format = 3 (btree)
> > core.size = 74027919512570268
> > core.nblocks = 0
> > core.dmevmask = 0x38020000
> > core.dmstate = 273
> These all look pretty wierd... I'd start with reseting all these to
> sane default values, then run repair again. I created a file like
> yours, and repair was OK with it, so possibly there'll be some other
> issues - send me the repair output if it still fails after resetting.
> So, the db commands would be something like:
> # xfs_db -x /dev/mdXXX
> xfs_db> inode 134762498
> xfs_db> write core.format 2
> xfs_db> write core.size 0
> xfs_db> write core.dmevmask 0
> xfs_db> write core.dmstate 0
> xfs_db> quit
> then run xfs_repair again and see how that goes.
after this xfs_repair give me the the same error in an other inode.
Yesterday I test this with all the inodes (apply on a dd image) but I
was only set 'write core.format 2'
After 25 steps with this error the xfs_repair was finishd. I mount the
imgae an look in. There was no directory with data. Only lost+found with
7GB files an directorys looks like 12312312312