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@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
