btrfs volume silently fails to mount

lynix · 2015-03-27 20:02:07

I'm having a very strange problem mounting a multi-disk btrfs volume.

The volume consists of four LUKS-encrypted partitions (RAID1) and is well recognized by btrfs:

[root@nasbox ~]# btrfs fi show

Label: 'archive'  uuid: 3818eedb-5379-4c40-9d3d-bd91f60d9094
	Total devices 4 FS bytes used 3.02TiB
	devid    1 size 1.82TiB used 1.61TiB path /dev/mapper/archive1-plain
	devid    2 size 1.82TiB used 1.61TiB path /dev/mapper/archive2-plain
	devid    4 size 2.00TiB used 1.69TiB path /dev/mapper/archive4-plain
	devid    5 size 2.00TiB used 1.69TiB path /dev/mapper/archive3-plain

When trying to mount it, the disks scratch for a few seconds, and I get positive feedback...

[root@nasbox ~]# mount -v /mnt/archive
mount: /dev/mapper/archive1-plain mounted on /mnt/archive.
[root@nasbox ~]# echo $?
0

... but the volume is in fact not mounted:

[root@nasbox ~]# mount | grep /mnt/archive
[root@nasbox ~]# ls -lh /mnt/archive
total 0

Kernel log does not show anything either.

Any ideas what could be wrong?

Last edited by lynix (2015-03-27 20:02:43)

lynix · 2015-03-27 20:34:53

Some additional info: I'm experiencing the problem since upgrading my system today.

This contained a kernel upgrade from 3.18.6-1 to 3.19.2-1, but neither upgrading to 3.19.3-1 nor downgrading back to 3.18.6-1 fixed the issue. Same thing for 'btrfs-progs' (3.18-1 vs. 3.19-1).

Here's the list of packages that were upgraded:

avahi (0.6.31-14 -> 0.6.31-15)
btrfs-progs (3.18.2-1 -> 3.19-1)
cairo (1.14.0-2 -> 1.14.2-1)
curl (7.40.0-1 -> 7.41.0-1)
e2fsprogs (1.42.12-1 -> 1.42.12-2)
ffmpeg (1:2.6-2 -> 1:2.6.1-1)
git (2.3.3-1 -> 2.3.4-1)
gnupg (2.1.2-1 -> 2.1.2-2)
harfbuzz (0.9.38-1 -> 0.9.40-1)
iproute2 (3.18.0-1 -> 3.19.0-1)
kmod (19-1 -> 20-1)
libcups (2.0.2-1 -> 2.0.2-3)
libdrm (2.4.59-1 -> 2.4.60-2)
libseccomp (2.1.1-1 -> 2.2.0-1)
libtasn1 (4.2-1 -> 4.3-1)
libutil-linux (2.25.2-1 -> 2.26.1-3)
libvdpau (0.9-1 -> 1.1-1)
libx11 (1.6.2-2 -> 1.6.3-1)
libx264 (2:142.20140826-1 -> 2:144.20150223-1)
libxdmcp (1.1.1-2 -> 1.1.2-1)
linux (3.18.6-1 -> 3.19.2-1)
llvm-libs (3.5.1-1 -> 3.6.0-3)
logrotate (3.8.8-2 -> 3.8.9-1)
lua (5.2.3-1 -> 5.2.4-1)
mc (4.8.13-1 -> 4.8.14-1)
mesa (10.4.6-1 -> 10.5.1-2)
mesa-libgl (10.4.6-1 -> 10.5.1-2)
openssh (6.7p1-1 -> 6.8p1-2)
openssl (1.0.2-1 -> 1.0.2.a-1)
pacman-mirrorlist (20150228-1 -> 20150315-1)
patch (2.7.4-1 -> 2.7.5-1)
postfix (3.0.0-2 -> 3.0.0-3)
shadow (4.2.1-2 -> 4.2.1-3)
tzdata (2015a-1 -> 2015b-1)
util-linux (2.25.2-1 -> 2.26.1-3)
vim (7.4.617-1 -> 7.4.663-1)
vim-runtime (7.4.617-1 -> 7.4.663-1)

WorMzy · 2015-03-27 20:35:44

Anything in dmesg/journal following a mount attempt?

lynix · 2015-03-27 20:37:21

No, nothing unfortunately:

[   78.023835] BTRFS: device label archive devid 5 transid 239454 /dev/dm-4
[   81.580625] BTRFS: device label archive devid 2 transid 239454 /dev/dm-5
[   85.122921] BTRFS: device label archive devid 1 transid 239454 /dev/dm-6
[   86.102304] BTRFS: device label archive devid 4 transid 239454 /dev/dm-7
[   87.313129] BTRFS info (device dm-7): disk space caching is enabled

Exact same output as on successful mount.

Think I'll try booting from a Live USB image, but this is difficult as the box is a headless NAS

lynix · 2015-03-27 20:51:02

Tried an Arch Live image with kernel 3.18.6-1: mounted successfully.
So at least the volume is not corrupt

Guess I'll have to downgrade packages until I get it working again...

lynix · 2015-04-01 20:14:11

Strange finding: looks like it is the mount point that is causing this... Mounting the same volume somewhere else works just fine.

Arch Linux

#1 2015-03-27 20:02:07

btrfs volume silently fails to mount

#2 2015-03-27 20:34:53

Re: btrfs volume silently fails to mount

#3 2015-03-27 20:35:44

Re: btrfs volume silently fails to mount

#4 2015-03-27 20:37:21

Re: btrfs volume silently fails to mount

#5 2015-03-27 20:51:02

Re: btrfs volume silently fails to mount

#6 2015-04-01 20:14:11

Re: btrfs volume silently fails to mount

Board footer