----- "Eddy Zhao" <eddy.y.zhao@xxxxxxxxx> wrote:
> > I don't recommend you pull the usb disk out while the filesystem is
> > mounted (if you can avoid it).
> Doing that to emulate power loss scenario our device might experience.
> > I would start by looking through the change history for
> > and paying particular attention to anything to do with inode
> Not quite familiar with XFS code :(
We all start somewhere!
> > Or try some intermediate kernels and see if you can narrow the fix
> down to a set of
> > changes.
> I'll try to bisect (It will take some time...)
> > # mount /dev/sda1 /mnt/
> > UDF-fs: No VRS found
> > XFS mounting filesystem sda1
> > Starting XFS recovery on filesystem: sda1 (dev: sda1)
> > Filesystem "sda1": xfs_inode_recover: Bad inode magic number, dino
> > = 0xc8266700, dino bp = 0xc8281b40, ino = 0
> Because XFS log is OK to 2.6.28 system, which means the log is correct
> in itself.
> Would it be easy for you to debug the problem by compare 2.6.10 log
> recovery code fail point and the corresponding 2.6.28 log record?
Easy? Not exactly. Diff'ing 2.6.10 version of fs/xfs/xfs_log_recover.c
with mainline shows over 300 differences. If you really want to be able
to replay the log on a different system it really has to be running the
same version of XFS for there to be any chance of it working properly.
It should also be the same architecture too - is it possible you have a
32 bit kernel on the 2.6.10 system and a 64 bit kernel on the 2.6.28
system? If so then this fix might help
I think it went into 2.6.18.
> xfs mailing list