* Re: Volume fine on x86_64, corruption on ARM
2013-01-27 22:52 Volume fine on x86_64, corruption on ARM Lluís Batlle i Rossell
@ 2013-01-28 1:52 ` Eric Sandeen
2013-01-28 8:03 ` Lluís Batlle i Rossell
2013-01-28 10:46 ` Stan Hoeppner
` (3 subsequent siblings)
4 siblings, 1 reply; 18+ messages in thread
From: Eric Sandeen @ 2013-01-28 1:52 UTC (permalink / raw)
To: Lluís Batlle i Rossell; +Cc: xfs
On Jan 27, 2013, at 4:52 PM, Lluís Batlle i Rossell <viric@viric.name> wrote:
> Hello,
>
> I'm using linux 3.7.3 in both machines (x86_64 and armv5tel), and I created
> a volume in x86_64 to be the rootfs for the ARM. All fine, until I plugged it
> into the ARM (Log below).
>
Is it stock 3.7.3 on arm, or are there any patches affecting xfs? There were dodgy arm/xfs patches floating around a few years ago, just want to be sure they are not in use in your case...
Thanks,
Eric
> Given the corruption, I used xfs_repair in the x86_64, moved a lot of files into lost+found, plugged it back to the ARM, booted, and corruption again.
>
> In the same USB HD, in the same ARM, and this same way, I've used succesfully
> ext4 and btrfs for a long time. Is there any known issue with ARM?
>
> Thank you,
> Lluís.
>
> ----------------------
> starting systemd...
> systemd 197 running in system mode. (+PAM -LIBWRAP -AUDIT -SELINUX +IMA +SYSVINIT -LIBCRYPTSETUP +GCRYPT +ACL +XZ)
>
> Welcome to NixOS 0.2pre-4eb2b09-af495e0!
>
> Failed to insert module 'autofs4'
> dea96000: 58 46 53 42 00 00 10 00 00 00 00 00 01 bd 26 f0 XFSB..........&.
> XFS (sda1): Internal error xfs_da_do_buf(2) at line 2192 of file fs/xfs/xfs_da_btree.c. Caller 0xbf057e68
>
> [<c000ecd0>] (unwind_backtrace+0x0/0xfc) from [<c052d9c8>] (dump_stack+0x20/0x24)
> [<c052d9c8>] (dump_stack+0x20/0x24) from [<bf016690>] (xfs_error_report+0x64/0x70 [xfs])
> [<bf016690>] (xfs_error_report+0x64/0x70 [xfs]) from [<bf016700>] (xfs_corruption_error+0x64/0x80 [xfs])
> [<bf016700>] (xfs_corruption_error+0x64/0x80 [xfs]) from [<bf051a28>] (xfs_da_read_buf+0x1ac/0x27c [xfs])
> [<bf051a28>] (xfs_da_read_buf+0x1ac/0x27c [xfs]) from [<bf057e68>] (xfs_dir2_leaf_readbuf+0x220/0x5f0 [xfs])
> [<bf057e68>] (xfs_dir2_leaf_readbuf+0x220/0x5f0 [xfs]) from [<bf058784>] (xfs_dir2_leaf_getdents+0x12c/0x3ec [xfs])
> [<bf058784>] (xfs_dir2_leaf_getdents+0x12c/0x3ec [xfs]) from [<bf0545dc>] (xfs_readdir+0xf0/0x170 [xfs])
> [<bf0545dc>] (xfs_readdir+0xf0/0x170 [xfs]) from [<bf017cc8>] (xfs_file_readdir+0x58/0x68 [xfs])
> [<bf017cc8>] (xfs_file_readdir+0x58/0x68 [xfs]) from [<c00ff4a4>] (vfs_readdir+0x8c/0xb0)
> [<c00ff4a4>] (vfs_readdir+0x8c/0xb0) from [<c00ff618>] (sys_getdents64+0x78/0xd8)
> [<c00ff618>] (sys_getdents64+0x78/0xd8) from [<c0009340>] (ret_fast_syscall+0x0/0x2c)
> XFS (sda1): Corruption detected. Unmount and run xfs_repair
> dea96000: 58 46 53 42 00 00 10 00 00 00 00 00 01 bd 26 f0 XFSB..........&.
> XFS (sda1): Internal error xfs_da_do_buf(2) at line 2192 of file fs/xfs/xfs_da_btree.c. Caller 0xbf057e68
>
> [<c000ecd0>] (unwind_backtrace+0x0/0xfc) from [<c052d9c8>] (dump_stack+0x20/0x24)
> [<c052d9c8>] (dump_stack+0x20/0x24) from [<bf016690>] (xfs_error_report+0x64/0x70 [xfs])
> [<bf016690>] (xfs_error_report+0x64/0x70 [xfs]) from [<bf016700>] (xfs_corruption_error+0x64/0x80 [xfs])
> [<bf016700>] (xfs_corruption_error+0x64/0x80 [xfs]) from [<bf051a28>] (xfs_da_read_buf+0x1ac/0x27c [xfs])
> [<bf051a28>] (xfs_da_read_buf+0x1ac/0x27c [xfs]) from [<bf057e68>] (xfs_dir2_leaf_readbuf+0x220/0x5f0 [xfs])
> [<bf057e68>] (xfs_dir2_leaf_readbuf+0x220/0x5f0 [xfs]) from [<bf058784>] (xfs_dir2_leaf_getdents+0x12c/0x3ec [xfs])
> [<bf058784>] (xfs_dir2_leaf_getdents+0x12c/0x3ec [xfs]) from [<bf0545dc>] (xfs_readdir+0xf0/0x170 [xfs])
> [<bf0545dc>] (xfs_readdir+0xf0/0x170 [xfs]) from [<bf017cc8>] (xfs_file_readdir+0x58/0x68 [xfs])
> [<bf017cc8>] (xfs_file_readdir+0x58/0x68 [xfs]) from [<c00ff4a4>] (vfs_readdir+0x8c/0xb0)
> [<c00ff4a4>] (vfs_readdir+0x8c/0xb0) from [<c00ff618>] (sys_getdents64+0x78/0xd8)
> [<c00ff618>] (sys_getdents64+0x78/0xd8) from [<c0009340>] (ret_fast_syscall+0x0/0x2c)
> XFS (sda1): Corruption detected. Unmount and run xfs_repair
> Failed to load default target: No such file or directory
> Trying to load rescue target...
> Failed to load rescue target: No such file or directory
> systemd-cgroups-agent[1324]: Failed to get D-Bus connection: Failed to connect to socket /org/freedesktop/systemd1/private: Connection refused
>
>
>
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs
>
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: Volume fine on x86_64, corruption on ARM
2013-01-28 1:52 ` Eric Sandeen
@ 2013-01-28 8:03 ` Lluís Batlle i Rossell
0 siblings, 0 replies; 18+ messages in thread
From: Lluís Batlle i Rossell @ 2013-01-28 8:03 UTC (permalink / raw)
To: Eric Sandeen; +Cc: xfs
On Sun, Jan 27, 2013 at 07:52:45PM -0600, Eric Sandeen wrote:
> On Jan 27, 2013, at 4:52 PM, Lluís Batlle i Rossell <viric@viric.name> wrote:
>
> > Hello,
> >
> > I'm using linux 3.7.3 in both machines (x86_64 and armv5tel), and I created
> > a volume in x86_64 to be the rootfs for the ARM. All fine, until I plugged it
> > into the ARM (Log below).
> >
>
> Is it stock 3.7.3 on arm, or are there any patches affecting xfs? There were
> dodgy arm/xfs patches floating around a few years ago, just want to be sure
> they are not in use in your case...
Stock 3.7.3. The sheevaplug computer is supported in stock kernel, so I don't
use any patch.
Regards,
Lluís.
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Volume fine on x86_64, corruption on ARM
2013-01-27 22:52 Volume fine on x86_64, corruption on ARM Lluís Batlle i Rossell
2013-01-28 1:52 ` Eric Sandeen
@ 2013-01-28 10:46 ` Stan Hoeppner
2013-01-28 13:37 ` Lluís Batlle i Rossell
2013-01-28 22:37 ` Eric Sandeen
` (2 subsequent siblings)
4 siblings, 1 reply; 18+ messages in thread
From: Stan Hoeppner @ 2013-01-28 10:46 UTC (permalink / raw)
To: Lluís Batlle i Rossell; +Cc: xfs
On 1/27/2013 4:52 PM, Lluís Batlle i Rossell wrote:
> ----------------------
> starting systemd...
> systemd 197 running in system mode. (+PAM -LIBWRAP -AUDIT -SELINUX +IMA +SYSVINIT -LIBCRYPTSETUP +GCRYPT +ACL +XZ)
>
> Welcome to NixOS 0.2pre-4eb2b09-af495e0!
>
> Failed to insert module 'autofs4'
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> dea96000: 58 46 53 42 00 00 10 00 00 00 00 00 01 bd 26 f0 XFSB..........&.
> XFS (sda1): Internal error xfs_da_do_buf(2) at line 2192 of file fs/xfs/xfs_da_btree.c. Caller 0xbf057e68
...
https://wiki.archlinux.org/index.php/Autofs
This document outlines the procedure needed to set up AutoFS, a package
that provides support for automounting removable media or network shares
when they are inserted or accessed.
Your HDD is USB. Might the failure of this module to load have
something to do with the XFS problems?
Forgive me if my lack of experience with this is causing me to ask a
stupid question. I've never used, nor will I ever use, XFS with a USB
drive.
--
Stan
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: Volume fine on x86_64, corruption on ARM
2013-01-28 10:46 ` Stan Hoeppner
@ 2013-01-28 13:37 ` Lluís Batlle i Rossell
2013-01-28 17:10 ` Eric Sandeen
0 siblings, 1 reply; 18+ messages in thread
From: Lluís Batlle i Rossell @ 2013-01-28 13:37 UTC (permalink / raw)
To: Stan Hoeppner; +Cc: xfs
On Mon, Jan 28, 2013 at 04:46:57AM -0600, Stan Hoeppner wrote:
> On 1/27/2013 4:52 PM, Lluís Batlle i Rossell wrote:
>
> > ----------------------
> > starting systemd...
> > systemd 197 running in system mode. (+PAM -LIBWRAP -AUDIT -SELINUX +IMA +SYSVINIT -LIBCRYPTSETUP +GCRYPT +ACL +XZ)
> >
> > Welcome to NixOS 0.2pre-4eb2b09-af495e0!
> >
> > Failed to insert module 'autofs4'
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > dea96000: 58 46 53 42 00 00 10 00 00 00 00 00 01 bd 26 f0 XFSB..........&.
> > XFS (sda1): Internal error xfs_da_do_buf(2) at line 2192 of file fs/xfs/xfs_da_btree.c. Caller 0xbf057e68
> ...
> Your HDD is USB. Might the failure of this module to load have
> something to do with the XFS problems?
I don't think it is related; the failure to load the module is because the
module isn't there in my kernel. And that happens after the fs has been quite
used in the boot, it's not mount time.
> Forgive me if my lack of experience with this is causing me to ask a
> stupid question. I've never used, nor will I ever use, XFS with a USB
> drive.
Well, I didn't expect it to be any trouble :) I've XFS in other USB drives, but
before this, I only used them in x86_64. I might stop using XFS there.
Thank you,
Lluís.
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Volume fine on x86_64, corruption on ARM
2013-01-28 13:37 ` Lluís Batlle i Rossell
@ 2013-01-28 17:10 ` Eric Sandeen
0 siblings, 0 replies; 18+ messages in thread
From: Eric Sandeen @ 2013-01-28 17:10 UTC (permalink / raw)
To: Lluís Batlle i Rossell; +Cc: Stan Hoeppner, xfs
On 1/28/13 7:37 AM, Lluís Batlle i Rossell wrote:
> On Mon, Jan 28, 2013 at 04:46:57AM -0600, Stan Hoeppner wrote:
>> On 1/27/2013 4:52 PM, Lluís Batlle i Rossell wrote:
>>
>>> ----------------------
>>> starting systemd...
>>> systemd 197 running in system mode. (+PAM -LIBWRAP -AUDIT -SELINUX +IMA +SYSVINIT -LIBCRYPTSETUP +GCRYPT +ACL +XZ)
>>>
>>> Welcome to NixOS 0.2pre-4eb2b09-af495e0!
>>>
>>> Failed to insert module 'autofs4'
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>> dea96000: 58 46 53 42 00 00 10 00 00 00 00 00 01 bd 26 f0 XFSB..........&.
>>> XFS (sda1): Internal error xfs_da_do_buf(2) at line 2192 of file fs/xfs/xfs_da_btree.c. Caller 0xbf057e68
>> ...
>> Your HDD is USB. Might the failure of this module to load have
>> something to do with the XFS problems?
I doubt it.
> I don't think it is related; the failure to load the module is because the
> module isn't there in my kernel. And that happens after the fs has been quite
> used in the boot, it's not mount time.
>
>> Forgive me if my lack of experience with this is causing me to ask a
>> stupid question. I've never used, nor will I ever use, XFS with a USB
>> drive.
>
> Well, I didn't expect it to be any trouble :) I've XFS in other USB drives, but
> before this, I only used them in x86_64. I might stop using XFS there.
It should work, and I'd like to find out why it's not. It used to. :)
But I'm a little low on time. Would you be willing to spot-check some older
kernels, and see if/when this regressed?
Thanks,
-Eric
> Thank you,
> Lluís.
>
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs
>
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Volume fine on x86_64, corruption on ARM
2013-01-27 22:52 Volume fine on x86_64, corruption on ARM Lluís Batlle i Rossell
2013-01-28 1:52 ` Eric Sandeen
2013-01-28 10:46 ` Stan Hoeppner
@ 2013-01-28 22:37 ` Eric Sandeen
2013-01-28 22:40 ` Lluís Batlle i Rossell
2013-02-03 22:46 ` Brian Foster
2013-02-27 14:51 ` Eric Sandeen
4 siblings, 1 reply; 18+ messages in thread
From: Eric Sandeen @ 2013-01-28 22:37 UTC (permalink / raw)
To: Lluís Batlle i Rossell; +Cc: xfs
On 1/27/13 4:52 PM, Lluís Batlle i Rossell wrote:
> Hello,
>
> I'm using linux 3.7.3 in both machines (x86_64 and armv5tel), and I created
> a volume in x86_64 to be the rootfs for the ARM. All fine, until I plugged it
> into the ARM (Log below).
>
> Given the corruption, I used xfs_repair in the x86_64, moved a lot of files into lost+found, plugged it back to the ARM, booted, and corruption again.
>
> In the same USB HD, in the same ARM, and this same way, I've used succesfully
> ext4 and btrfs for a long time. Is there any known issue with ARM?
>
> Thank you,
> Lluís.
>
> ----------------------
> starting systemd...
> systemd 197 running in system mode. (+PAM -LIBWRAP -AUDIT -SELINUX +IMA +SYSVINIT -LIBCRYPTSETUP +GCRYPT +ACL +XZ)
>
> Welcome to NixOS 0.2pre-4eb2b09-af495e0!
>
> Failed to insert module 'autofs4'
> dea96000: 58 46 53 42 00 00 10 00 00 00 00 00 01 bd 26 f0 XFSB..........&.
> XFS (sda1): Internal error xfs_da_do_buf(2) at line 2192 of file fs/xfs/xfs_da_btree.c. Caller 0xbf057e68
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?
-Eric
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Volume fine on x86_64, corruption on ARM
2013-01-28 22:37 ` Eric Sandeen
@ 2013-01-28 22:40 ` Lluís Batlle i Rossell
2013-01-28 22:45 ` Eric Sandeen
2013-01-31 20:19 ` Phillip Lougher
0 siblings, 2 replies; 18+ messages in thread
From: Lluís Batlle i Rossell @ 2013-01-28 22:40 UTC (permalink / raw)
To: Eric Sandeen; +Cc: xfs
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.
Regards,
Lluís.
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Volume fine on x86_64, corruption on ARM
2013-01-28 22:40 ` Lluís Batlle i Rossell
@ 2013-01-28 22:45 ` Eric Sandeen
2013-01-28 22:50 ` Lluís Batlle i Rossell
2013-01-29 5:21 ` Stan Hoeppner
2013-01-31 20:19 ` Phillip Lougher
1 sibling, 2 replies; 18+ messages in thread
From: Eric Sandeen @ 2013-01-28 22:45 UTC (permalink / raw)
To: Lluís Batlle i Rossell; +Cc: xfs
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?
>
> Thank you for testing! You mean that your test went fine, right?
with the simple test on the above machines, yes, it was fine.
> 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?
> 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.
> 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?
-Eric
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Volume fine on x86_64, corruption on ARM
2013-01-28 22:45 ` Eric Sandeen
@ 2013-01-28 22:50 ` Lluís Batlle i Rossell
2013-01-29 5:21 ` Stan Hoeppner
1 sibling, 0 replies; 18+ messages in thread
From: Lluís Batlle i Rossell @ 2013-01-28 22:50 UTC (permalink / raw)
To: Eric Sandeen; +Cc: xfs
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@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Volume fine on x86_64, corruption on ARM
2013-01-28 22:45 ` Eric Sandeen
2013-01-28 22:50 ` Lluís Batlle i Rossell
@ 2013-01-29 5:21 ` Stan Hoeppner
1 sibling, 0 replies; 18+ messages in thread
From: Stan Hoeppner @ 2013-01-29 5:21 UTC (permalink / raw)
To: Eric Sandeen; +Cc: Lluís Batlle i Rossell, xfs
On 1/28/2013 4:45 PM, Eric Sandeen wrote:
> On 1/28/13 4:40 PM, Lluís Batlle i Rossell wrote:
>> 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?
Worth considering, the move may not be the problem but simply a
manifestation of it. Creating the filesystem directly on the Shiva plug
and testing it may be instructive at this point as well.
--
Stan
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Volume fine on x86_64, corruption on ARM
2013-01-28 22:40 ` Lluís Batlle i Rossell
2013-01-28 22:45 ` Eric Sandeen
@ 2013-01-31 20:19 ` Phillip Lougher
1 sibling, 0 replies; 18+ messages in thread
From: Phillip Lougher @ 2013-01-31 20:19 UTC (permalink / raw)
To: linux-xfs
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Volume fine on x86_64, corruption on ARM
2013-01-27 22:52 Volume fine on x86_64, corruption on ARM Lluís Batlle i Rossell
` (2 preceding siblings ...)
2013-01-28 22:37 ` Eric Sandeen
@ 2013-02-03 22:46 ` Brian Foster
2013-02-04 17:46 ` Lluís Batlle i Rossell
2013-02-27 14:51 ` Eric Sandeen
4 siblings, 1 reply; 18+ messages in thread
From: Brian Foster @ 2013-02-03 22:46 UTC (permalink / raw)
To: Lluís Batlle i Rossell; +Cc: xfs
On 01/27/2013 05:52 PM, Lluís Batlle i Rossell wrote:
> Hello,
>
> I'm using linux 3.7.3 in both machines (x86_64 and armv5tel), and I created
> a volume in x86_64 to be the rootfs for the ARM. All fine, until I plugged it
> into the ARM (Log below).
>
> Given the corruption, I used xfs_repair in the x86_64, moved a lot of files into lost+found, plugged it back to the ARM, booted, and corruption again.
>
> In the same USB HD, in the same ARM, and this same way, I've used succesfully
> ext4 and btrfs for a long time. Is there any known issue with ARM?
>
FYI, I played around with my old sheevaplug a bit and so far, only
reproduced what I think are some USB (possibly hardware) issues. I
started with a 3.8.0-rc6 kernel and an sdcard and was reproducing
consistent USB resets leading to all sorts of errors.
I went back to 3.7.3 and replaced the sdcard with a thumb drive and
reproduced corruption errors several times on a reboot (not on initial
boot iirc). This required an fsck or reformat from my host system. I was
also occasionally reproducing USB debounce errors that required me to
power cycle and remove/attach the USB drive, which led me to try several
boot attempts with a clean power cycle and attaching the USB drive after
the bootloader (u-boot) has initialized, and with that sequence I
couldn't reproduce the error.
Unfortunately, I then tried several soft reboot cycles with the drive
attached and the error hasn't fired, so I can't make any serious
conclusion from that other than the possibility of flaky drivers or
hardware. Does your XFS rootfs _always_ fail, or can you get it to boot
occasionally or with a power cycle? This, of course, could be completely
unrelated to the issue you observe. I haven't tried a non-XFS filesystem
yet on this drive either. I'll play with it more when I have some more time.
Brian
> Thank you,
> Lluís.
>
> ----------------------
> starting systemd...
> systemd 197 running in system mode. (+PAM -LIBWRAP -AUDIT -SELINUX +IMA +SYSVINIT -LIBCRYPTSETUP +GCRYPT +ACL +XZ)
>
> Welcome to NixOS 0.2pre-4eb2b09-af495e0!
>
> Failed to insert module 'autofs4'
> dea96000: 58 46 53 42 00 00 10 00 00 00 00 00 01 bd 26 f0 XFSB..........&.
> XFS (sda1): Internal error xfs_da_do_buf(2) at line 2192 of file fs/xfs/xfs_da_btree.c. Caller 0xbf057e68
>
> [<c000ecd0>] (unwind_backtrace+0x0/0xfc) from [<c052d9c8>] (dump_stack+0x20/0x24)
> [<c052d9c8>] (dump_stack+0x20/0x24) from [<bf016690>] (xfs_error_report+0x64/0x70 [xfs])
> [<bf016690>] (xfs_error_report+0x64/0x70 [xfs]) from [<bf016700>] (xfs_corruption_error+0x64/0x80 [xfs])
> [<bf016700>] (xfs_corruption_error+0x64/0x80 [xfs]) from [<bf051a28>] (xfs_da_read_buf+0x1ac/0x27c [xfs])
> [<bf051a28>] (xfs_da_read_buf+0x1ac/0x27c [xfs]) from [<bf057e68>] (xfs_dir2_leaf_readbuf+0x220/0x5f0 [xfs])
> [<bf057e68>] (xfs_dir2_leaf_readbuf+0x220/0x5f0 [xfs]) from [<bf058784>] (xfs_dir2_leaf_getdents+0x12c/0x3ec [xfs])
> [<bf058784>] (xfs_dir2_leaf_getdents+0x12c/0x3ec [xfs]) from [<bf0545dc>] (xfs_readdir+0xf0/0x170 [xfs])
> [<bf0545dc>] (xfs_readdir+0xf0/0x170 [xfs]) from [<bf017cc8>] (xfs_file_readdir+0x58/0x68 [xfs])
> [<bf017cc8>] (xfs_file_readdir+0x58/0x68 [xfs]) from [<c00ff4a4>] (vfs_readdir+0x8c/0xb0)
> [<c00ff4a4>] (vfs_readdir+0x8c/0xb0) from [<c00ff618>] (sys_getdents64+0x78/0xd8)
> [<c00ff618>] (sys_getdents64+0x78/0xd8) from [<c0009340>] (ret_fast_syscall+0x0/0x2c)
> XFS (sda1): Corruption detected. Unmount and run xfs_repair
> dea96000: 58 46 53 42 00 00 10 00 00 00 00 00 01 bd 26 f0 XFSB..........&.
> XFS (sda1): Internal error xfs_da_do_buf(2) at line 2192 of file fs/xfs/xfs_da_btree.c. Caller 0xbf057e68
>
> [<c000ecd0>] (unwind_backtrace+0x0/0xfc) from [<c052d9c8>] (dump_stack+0x20/0x24)
> [<c052d9c8>] (dump_stack+0x20/0x24) from [<bf016690>] (xfs_error_report+0x64/0x70 [xfs])
> [<bf016690>] (xfs_error_report+0x64/0x70 [xfs]) from [<bf016700>] (xfs_corruption_error+0x64/0x80 [xfs])
> [<bf016700>] (xfs_corruption_error+0x64/0x80 [xfs]) from [<bf051a28>] (xfs_da_read_buf+0x1ac/0x27c [xfs])
> [<bf051a28>] (xfs_da_read_buf+0x1ac/0x27c [xfs]) from [<bf057e68>] (xfs_dir2_leaf_readbuf+0x220/0x5f0 [xfs])
> [<bf057e68>] (xfs_dir2_leaf_readbuf+0x220/0x5f0 [xfs]) from [<bf058784>] (xfs_dir2_leaf_getdents+0x12c/0x3ec [xfs])
> [<bf058784>] (xfs_dir2_leaf_getdents+0x12c/0x3ec [xfs]) from [<bf0545dc>] (xfs_readdir+0xf0/0x170 [xfs])
> [<bf0545dc>] (xfs_readdir+0xf0/0x170 [xfs]) from [<bf017cc8>] (xfs_file_readdir+0x58/0x68 [xfs])
> [<bf017cc8>] (xfs_file_readdir+0x58/0x68 [xfs]) from [<c00ff4a4>] (vfs_readdir+0x8c/0xb0)
> [<c00ff4a4>] (vfs_readdir+0x8c/0xb0) from [<c00ff618>] (sys_getdents64+0x78/0xd8)
> [<c00ff618>] (sys_getdents64+0x78/0xd8) from [<c0009340>] (ret_fast_syscall+0x0/0x2c)
> XFS (sda1): Corruption detected. Unmount and run xfs_repair
> Failed to load default target: No such file or directory
> Trying to load rescue target...
> Failed to load rescue target: No such file or directory
> systemd-cgroups-agent[1324]: Failed to get D-Bus connection: Failed to connect to socket /org/freedesktop/systemd1/private: Connection refused
>
>
>
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs
>
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: Volume fine on x86_64, corruption on ARM
2013-02-03 22:46 ` Brian Foster
@ 2013-02-04 17:46 ` Lluís Batlle i Rossell
0 siblings, 0 replies; 18+ messages in thread
From: Lluís Batlle i Rossell @ 2013-02-04 17:46 UTC (permalink / raw)
To: Brian Foster; +Cc: xfs
On Sun, Feb 03, 2013 at 05:46:10PM -0500, Brian Foster wrote:
> On 01/27/2013 05:52 PM, Lluís Batlle i Rossell wrote:
> > Hello,
> >
> > I'm using linux 3.7.3 in both machines (x86_64 and armv5tel), and I created
> > a volume in x86_64 to be the rootfs for the ARM. All fine, until I plugged it
> > into the ARM (Log below).
> >
> > Given the corruption, I used xfs_repair in the x86_64, moved a lot of files into lost+found, plugged it back to the ARM, booted, and corruption again.
> >
> > In the same USB HD, in the same ARM, and this same way, I've used succesfully
> > ext4 and btrfs for a long time. Is there any known issue with ARM?
> >
>
> FYI, I played around with my old sheevaplug a bit and so far, only
> reproduced what I think are some USB (possibly hardware) issues. I
> started with a 3.8.0-rc6 kernel and an sdcard and was reproducing
> consistent USB resets leading to all sorts of errors.
>
> I went back to 3.7.3 and replaced the sdcard with a thumb drive and
> reproduced corruption errors several times on a reboot (not on initial
> boot iirc). This required an fsck or reformat from my host system. I was
> also occasionally reproducing USB debounce errors that required me to
> power cycle and remove/attach the USB drive, which led me to try several
> boot attempts with a clean power cycle and attaching the USB drive after
> the bootloader (u-boot) has initialized, and with that sequence I
> couldn't reproduce the error.
>
> Unfortunately, I then tried several soft reboot cycles with the drive
> attached and the error hasn't fired, so I can't make any serious
> conclusion from that other than the possibility of flaky drivers or
> hardware. Does your XFS rootfs _always_ fail, or can you get it to boot
> occasionally or with a power cycle? This, of course, could be completely
> unrelated to the issue you observe. I haven't tried a non-XFS filesystem
> yet on this drive either. I'll play with it more when I have some more time.
Sorry, I'm on a trip, and I can't test this soon.
I used the same USB HD with the same kernel very well, with reiserfs and btrfs,
for many months (running fine with previous kernels too).
I tried three times to boot with XFS, and the corruption came up before systemd
could start properly every time.
I switched to Ext4, and I've had no problem since then either. That's why I
concluded it was only XFS having the problem.
Thank you for your time!
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Volume fine on x86_64, corruption on ARM
2013-01-27 22:52 Volume fine on x86_64, corruption on ARM Lluís Batlle i Rossell
` (3 preceding siblings ...)
2013-02-03 22:46 ` Brian Foster
@ 2013-02-27 14:51 ` Eric Sandeen
4 siblings, 0 replies; 18+ messages in thread
From: Eric Sandeen @ 2013-02-27 14:51 UTC (permalink / raw)
To: Lluís Batlle i Rossell; +Cc: xfs
On 1/27/13 4:52 PM, Lluís Batlle i Rossell wrote:
> Hello,
>
> I'm using linux 3.7.3 in both machines (x86_64 and armv5tel), and I created
> a volume in x86_64 to be the rootfs for the ARM. All fine, until I plugged it
> into the ARM (Log below).
>
> Given the corruption, I used xfs_repair in the x86_64, moved a lot of files into lost+found, plugged it back to the ARM, booted, and corruption again.
>
> In the same USB HD, in the same ARM, and this same way, I've used succesfully
> ext4 and btrfs for a long time. Is there any known issue with ARM?
How is this kernel compiled, any chance that it is cross-compiled?
Could you try tracing xfs when this occurs?
You can use sysfs/debugfs to do it:
This should do it:
# mount -t debugfs none /sys/kernel/debug
# echo 1 > /sys/kernel/debug/tracing/tracing_enabled
# echo 1 > /sys/kernel/debug/tracing/events/xfs/xfs_da_btree_corrupt/enable
<run your failing run>
# cat /sys/kernel/debug/tracing/trace
-Eric
> Thank you,
> Lluís.
>
> ----------------------
> starting systemd...
> systemd 197 running in system mode. (+PAM -LIBWRAP -AUDIT -SELINUX +IMA +SYSVINIT -LIBCRYPTSETUP +GCRYPT +ACL +XZ)
>
> Welcome to NixOS 0.2pre-4eb2b09-af495e0!
>
> Failed to insert module 'autofs4'
> dea96000: 58 46 53 42 00 00 10 00 00 00 00 00 01 bd 26 f0 XFSB..........&.
> XFS (sda1): Internal error xfs_da_do_buf(2) at line 2192 of file fs/xfs/xfs_da_btree.c. Caller 0xbf057e68
>
> [<c000ecd0>] (unwind_backtrace+0x0/0xfc) from [<c052d9c8>] (dump_stack+0x20/0x24)
> [<c052d9c8>] (dump_stack+0x20/0x24) from [<bf016690>] (xfs_error_report+0x64/0x70 [xfs])
> [<bf016690>] (xfs_error_report+0x64/0x70 [xfs]) from [<bf016700>] (xfs_corruption_error+0x64/0x80 [xfs])
> [<bf016700>] (xfs_corruption_error+0x64/0x80 [xfs]) from [<bf051a28>] (xfs_da_read_buf+0x1ac/0x27c [xfs])
> [<bf051a28>] (xfs_da_read_buf+0x1ac/0x27c [xfs]) from [<bf057e68>] (xfs_dir2_leaf_readbuf+0x220/0x5f0 [xfs])
> [<bf057e68>] (xfs_dir2_leaf_readbuf+0x220/0x5f0 [xfs]) from [<bf058784>] (xfs_dir2_leaf_getdents+0x12c/0x3ec [xfs])
> [<bf058784>] (xfs_dir2_leaf_getdents+0x12c/0x3ec [xfs]) from [<bf0545dc>] (xfs_readdir+0xf0/0x170 [xfs])
> [<bf0545dc>] (xfs_readdir+0xf0/0x170 [xfs]) from [<bf017cc8>] (xfs_file_readdir+0x58/0x68 [xfs])
> [<bf017cc8>] (xfs_file_readdir+0x58/0x68 [xfs]) from [<c00ff4a4>] (vfs_readdir+0x8c/0xb0)
> [<c00ff4a4>] (vfs_readdir+0x8c/0xb0) from [<c00ff618>] (sys_getdents64+0x78/0xd8)
> [<c00ff618>] (sys_getdents64+0x78/0xd8) from [<c0009340>] (ret_fast_syscall+0x0/0x2c)
> XFS (sda1): Corruption detected. Unmount and run xfs_repair
> dea96000: 58 46 53 42 00 00 10 00 00 00 00 00 01 bd 26 f0 XFSB..........&.
> XFS (sda1): Internal error xfs_da_do_buf(2) at line 2192 of file fs/xfs/xfs_da_btree.c. Caller 0xbf057e68
>
> [<c000ecd0>] (unwind_backtrace+0x0/0xfc) from [<c052d9c8>] (dump_stack+0x20/0x24)
> [<c052d9c8>] (dump_stack+0x20/0x24) from [<bf016690>] (xfs_error_report+0x64/0x70 [xfs])
> [<bf016690>] (xfs_error_report+0x64/0x70 [xfs]) from [<bf016700>] (xfs_corruption_error+0x64/0x80 [xfs])
> [<bf016700>] (xfs_corruption_error+0x64/0x80 [xfs]) from [<bf051a28>] (xfs_da_read_buf+0x1ac/0x27c [xfs])
> [<bf051a28>] (xfs_da_read_buf+0x1ac/0x27c [xfs]) from [<bf057e68>] (xfs_dir2_leaf_readbuf+0x220/0x5f0 [xfs])
> [<bf057e68>] (xfs_dir2_leaf_readbuf+0x220/0x5f0 [xfs]) from [<bf058784>] (xfs_dir2_leaf_getdents+0x12c/0x3ec [xfs])
> [<bf058784>] (xfs_dir2_leaf_getdents+0x12c/0x3ec [xfs]) from [<bf0545dc>] (xfs_readdir+0xf0/0x170 [xfs])
> [<bf0545dc>] (xfs_readdir+0xf0/0x170 [xfs]) from [<bf017cc8>] (xfs_file_readdir+0x58/0x68 [xfs])
> [<bf017cc8>] (xfs_file_readdir+0x58/0x68 [xfs]) from [<c00ff4a4>] (vfs_readdir+0x8c/0xb0)
> [<c00ff4a4>] (vfs_readdir+0x8c/0xb0) from [<c00ff618>] (sys_getdents64+0x78/0xd8)
> [<c00ff618>] (sys_getdents64+0x78/0xd8) from [<c0009340>] (ret_fast_syscall+0x0/0x2c)
> XFS (sda1): Corruption detected. Unmount and run xfs_repair
> Failed to load default target: No such file or directory
> Trying to load rescue target...
> Failed to load rescue target: No such file or directory
> systemd-cgroups-agent[1324]: Failed to get D-Bus connection: Failed to connect to socket /org/freedesktop/systemd1/private: Connection refused
>
>
>
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs
>
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 18+ messages in thread