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 finally). But I didn't try to run an xfs_repair straight after writing the files with x86_64. > > 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. Thank you, Lluís. _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs