LluÃs Batlle i Rossell <viric <at> viric.name> writes:
> 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?
> Thank you for testing! You mean that your test went fine, right?
> I run:
> mkfs.xfs /dev/sdb1
> Then I copied files to it. After the first crash in the arm, I used
>> xfs_repair on the
> x86_64. It created many lost+found. Then I tried again in the ARM, and it
> crashed again the same way.
I have tried to reproduce this using an armv5tel arch (qemu emulation),
running a stock 3.7.3 kernel. The test image was created on x86_64 with
a stock 3.7.3 kernel, and the test image then booted as the rootfs on the
No corruption of the filesystem occurred on the ARM, even with
parallel file writes/moves to 'encourage' the bug to appear.
The unmounted filesystem checked-out OK on the x86_64 using
Is there some missing information here or additional actions needed to
trigger this bug?