On Mon, Jan 28, 2013 at 04:45:10PM -0600, Eric Sandeen wrote:
> On 1/28/13 4:40 PM, Lluís Batlle i Rossell wrote:
> > On Mon, Jan 28, 2013 at 04:37:25PM -0600, Eric Sandeen wrote:
> >> So this was trying to read a dir2 directory metadata leaf block, and it
> >> didn't find the right magic.
> >> XFSB is superblock magic . . .
> >> I tested an image which (I think) contains every dir2 format, created on
> >> x86_64
> >> (under a RHEL6 3.2 kernel) and checked it on ARM (a raspberry pi 3.2.24
> >> kernel)
> >> so it's not really quite an apples to apples test.
> >> Does the filesystem check clean on x86_64 right after you create it? How
> >> did you
> >> create it?
> > I run:
> > mkfs.xfs /dev/sdb1
> > Then I copied files to it.
> On the x86_64 machine, right. Just to be sure, can you do an xfs_repair
> on x86_64 to be sure it's clean at this point?
I don't have the fs anymore... I have that disk in use right now (with ext4
But I didn't try to run an xfs_repair straight after writing the files with
> > After the first crash in the arm, I used xfs_repair on the
> > x86_64. It created many lost+found.
> capturing the repair output here would be helpful.
ouhm I can't find it now. Sorry.
> > Then I tried again in the ARM, and it
> > crashed again the same way.
> And by "tried again" do you mean you booted from that filesystem on
> the arm box, I guess, and then encountered the corruption?
Yes, the same procedure I used in the first case.
In the next days I'll try to get some quick test over a loop device or so, and
see if I can reproduce it.