[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-xfs
Subject:    Re: Volume fine on =?utf-8?b?eDg2XzY0LA==?= corruption on ARM
From:       Phillip Lougher <plougher () redhat ! com>
Date:       2013-01-31 20:19:20
Message-ID: loom.20130131T205839-735 () post ! gmane ! org
[Download RAW message or body]

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
ARM system.

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
xfs_check.

Is there some missing information here or additional actions needed to
trigger this bug?

Thanks

Phillip

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

[prev in list] [next in list] [prev in thread] [next in thread]