Volume fine on x86_64, corruption on ARM

Volume fine on x86_64, corruption on ARM

[Bill Webster]

[-- Attachment #1.1: Type: text/plain, Size: 30 bytes --]

Has this issue been resolved?

[-- Attachment #1.2: Type: text/html, Size: 55 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

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

Re: Volume fine on x86_64, corruption on ARM

[Dave Chinner]

On Fri, Feb 14, 2014 at 08:18:45PM -0700, Bill Webster wrote:
> Has this issue been resolved?

You need to be more specific abou tthe problem you are having than
the subject line....

http://xfs.org/index.php/XFS_FAQ#Q:_What_information_should_I_include_when_reporting_a_problem.3F

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

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

Re: Volume fine on x86_64, corruption on ARM

[Stan Hoeppner]

On 2/16/2014 4:21 PM, Dave Chinner wrote:
> On Fri, Feb 14, 2014 at 08:18:45PM -0700, Bill Webster wrote:
>> Has this issue been resolved?
> 
> You need to be more specific abou tthe problem you are having than
> the subject line....
> 
> http://xfs.org/index.php/XFS_FAQ#Q:_What_information_should_I_include_when_reporting_a_problem.3F

Bill seems to be replying to this thread from January 2013, apparently
assuming everyone would remember it simply by the subject line.  First
post of the thread:

http://oss.sgi.com/archives/xfs/2013-01/msg00494.html

Bill, in the future please reference the archived thread link, as I've
done here, so people know what you're talking about without them having
to dig through the archives.

Thanks,

Stan

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

Re: Volume fine on x86_64, corruption on ARM

[Eric Sandeen]

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

Re: Volume fine on x86_64, corruption on ARM

[Lluís Batlle i Rossell]

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

Re: Volume fine on x86_64, corruption on ARM

[Brian Foster]

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

Re: Volume fine on x86_64, corruption on ARM

[Phillip Lougher]

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

Re: Volume fine on x86_64, corruption on ARM

[Stan Hoeppner]

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

Re: Volume fine on x86_64, corruption on ARM

[Lluís Batlle i Rossell]

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

Re: Volume fine on x86_64, corruption on ARM

[Eric Sandeen]

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

Re: Volume fine on x86_64, corruption on ARM

[Lluís Batlle i Rossell]

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

Re: Volume fine on x86_64, corruption on ARM

[Eric Sandeen]

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

Re: Volume fine on x86_64, corruption on ARM

[Eric Sandeen]

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

Re: Volume fine on x86_64, corruption on ARM

[Lluís Batlle i Rossell]

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

Re: Volume fine on x86_64, corruption on ARM

[Stan Hoeppner]

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

Re: Volume fine on x86_64, corruption on ARM

[Lluís Batlle i Rossell]

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

Re: Volume fine on x86_64, corruption on ARM

[Eric Sandeen]

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

Volume fine on x86_64, corruption on ARM

[Lluís Batlle i Rossell]

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

[<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