failed to read the system array on sdX

failed to read the system array on sdX

[Hans-Kristian Bakke]

Hi

I suddenly got issues accessing a samba share and rebooted the server.
After the reboot the btrfs mount does not come up and prints the
following messages in dmesg:

[  530.881802] btrfs: device fsid 9302fc8f-15c6-46e9-9217-951d7423927c
devid 4 transid 138602 /dev/sdt
[  530.882734] btrfs: disk space caching is enabled
[  530.883697] btrfs: failed to read the system array on sdt
[  530.898188] btrfs: open_ctree failed

Probably some kind of issue with btrfs was the reason for the samba
share failing.
--
- All seven 4TB drives is in one btrfs RAID10 with no lvm/mdadm

btrfs fi show
Label: none  uuid: 9302fc8f-15c6-46e9-9217-951d7423927c
        Total devices 7 FS bytes used 9.91TiB
        devid    2 size 3.64TiB used 3.07TiB path /dev/sdm
        devid    3 size 3.64TiB used 3.07TiB path /dev/sds
        devid    4 size 3.64TiB used 3.07TiB path /dev/sdt
        devid    5 size 3.64TiB used 3.07TiB path /dev/sdo
        devid    6 size 3.64TiB used 3.07TiB path /dev/sdp
        devid    7 size 3.64TiB used 3.07TiB path /dev/sdq
        devid    8 size 3.64TiB used 3.07TiB path /dev/sdr

Btrfs v3.12

/etc/fstab:
UUID=9302fc8f-15c6-46e9-9217-951d7423927c   /btrfs
              btrfs   defaults,compress=lzo,noatime          0   2
UUID=9302fc8f-15c6-46e9-9217-951d7423927c   /storage/storage-vol0
              btrfs   defaults,subvol=storage-vol0,noatime   0   2

uname -a
Linux merkur 3.12.6 #1 SMP Sat Dec 21 02:23:32 CET 2013 x86_64 GNU/Linux

Hardware:
Supermicro Xeon server with 16GB ECC RAM, LSI HBAs and WD SE 4TB drives.

Adding recovery to mount options:
# mount /btrfs/
mount: wrong fs type, bad option, bad superblock on /dev/sdt,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so


----

What is the correct steps forward to mount my array again?

Best regards,
Hans-Kristian

Re: failed to read the system array on sdX

[Hans-Kristian Bakke]

Ok, I think I found the issue. The array was okay and mounted
successfully after running "btrfs device scan", and the samba issue
was unrelated and had something to do with winbind integration with AD
which the reboot cured after getting the btrfs store to mount.

It has always done this automatically for me on Debian Wheezy however,
but then I remembered that I removed the old btrfs-tools package when
installing btrfs-progs from git. I noticed that the btrfs-progra
package did an update-initramfs when installing which I guess is the
clue here. I is probably adding the old call of btrfsctl -a during
boot, while this is gone with btrfs-progs.

1. How can I manually add btrfs device scan to initramfs with
btrfs-progs like the debian package?
2. There is no uninstall target in the btrfs-tools Makefile. How am I
supposed to uninstall btrfs-progs if wanting to go back to older
versions (or newer)?



On 21 January 2014 22:31, Hans-Kristian Bakke <hkbakke@gmail.com> wrote:
> Hi
>
> I suddenly got issues accessing a samba share and rebooted the server.
> After the reboot the btrfs mount does not come up and prints the
> following messages in dmesg:
>
> [  530.881802] btrfs: device fsid 9302fc8f-15c6-46e9-9217-951d7423927c
> devid 4 transid 138602 /dev/sdt
> [  530.882734] btrfs: disk space caching is enabled
> [  530.883697] btrfs: failed to read the system array on sdt
> [  530.898188] btrfs: open_ctree failed
>
> Probably some kind of issue with btrfs was the reason for the samba
> share failing.
> --
> - All seven 4TB drives is in one btrfs RAID10 with no lvm/mdadm
>
> btrfs fi show
> Label: none  uuid: 9302fc8f-15c6-46e9-9217-951d7423927c
>         Total devices 7 FS bytes used 9.91TiB
>         devid    2 size 3.64TiB used 3.07TiB path /dev/sdm
>         devid    3 size 3.64TiB used 3.07TiB path /dev/sds
>         devid    4 size 3.64TiB used 3.07TiB path /dev/sdt
>         devid    5 size 3.64TiB used 3.07TiB path /dev/sdo
>         devid    6 size 3.64TiB used 3.07TiB path /dev/sdp
>         devid    7 size 3.64TiB used 3.07TiB path /dev/sdq
>         devid    8 size 3.64TiB used 3.07TiB path /dev/sdr
>
> Btrfs v3.12
>
> /etc/fstab:
> UUID=9302fc8f-15c6-46e9-9217-951d7423927c   /btrfs
>               btrfs   defaults,compress=lzo,noatime          0   2
> UUID=9302fc8f-15c6-46e9-9217-951d7423927c   /storage/storage-vol0
>               btrfs   defaults,subvol=storage-vol0,noatime   0   2
>
> uname -a
> Linux merkur 3.12.6 #1 SMP Sat Dec 21 02:23:32 CET 2013 x86_64 GNU/Linux
>
> Hardware:
> Supermicro Xeon server with 16GB ECC RAM, LSI HBAs and WD SE 4TB drives.
>
> Adding recovery to mount options:
> # mount /btrfs/
> mount: wrong fs type, bad option, bad superblock on /dev/sdt,
>        missing codepage or helper program, or other error
>        In some cases useful info is found in syslog - try
>        dmesg | tail  or so
>
>
> ----
>
> What is the correct steps forward to mount my array again?
>
> Best regards,
> Hans-Kristian

Re: failed to read the system array on sdX

[Duncan]

Hans-Kristian Bakke posted on Tue, 21 Jan 2014 23:09:58 +0100 as
excerpted:

> 2. There is no uninstall target in the btrfs-tools Makefile. How am I
> supposed to uninstall btrfs-progs if wanting to go back to older
> versions (or newer)?

As I run gentoo not debian, I won't try to answer the other.  However I 
can answer this, to /some/ extent anyway.

a) (probably not all that interesting to you) On gentoo there's a live-
git ebuild available.  The PM will track the files it installs just as it 
would for any other package.  (A fake-install to a temp location is done 
first and the files that appear there are automatically registered for 
tracking and later uninstall.  Then the fake install is copied to the 
live filesystem.)  If your distro has something similar...

b) As is often the case with in-development "leaf" packages that are 
mostly executables and documentation (that is, no libraries/headers/etc 
that other packages will need), a standard recommendation is to use the 
files directly from the build dir, without actually installing.

So you'd build btrfs, and any time you wanted to use it you'd simply cd 
to its build dir and do ./btrfs (or other command).  Then you'd simply 
delete the build dir to uninstall.

Of course you could manually copy individual files out of the build dir, 
say to your initr* build, if desired, and track the ones you did just as 
manually.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman