How to mount btrfs subvolume, it isn't working / mounting

Question

I just did:

# btrfs subvolume create /@srv

then:

# btrfs subvolume list /
ID 257 gen 73 top level 5 path @
ID 258 gen 71 top level 5 path @home
ID 260 gen 65 top level 257 path @srv

And added to /etc/fstab, like this:

/dev/mapper/fs--1--vg-root /home            btrfs   defaults,compress=zlib,subvol=@home 0       2
/dev/mapper/fs--1--vg-root /srv            btrfs   defaults,compress=zlib,subvol=@srv 0       2

...where /home is the default that come from Ubuntu's installation and /srv is the one that I manually added, based on what I'm seeing "as an example (i.e., /home)".

But it does not mount, look:

# mount /srv
mount: mount(2) failed: No such file or directory

Subdir /srv exists:

# file /srv
/srv: directory

What am I missing?

BTW, the subvolumes @ and @home are okay. But I am unable to create more subvolumes and mount it, side by side with, for example, @home.

Solution 1

Just tried it and found out, that you should specify subvol=/@ or subvol=/@home – with a leading slash.

So, my working /etc/fstab with one automount and one manually mountable subvolume now looks like this:

/dev/sdb /backup btrfs noatime,nodiratime,subvol=/@ 0 0
/dev/sdb /snapshots btrfs noauto,noatime,nodiratime,subvol=/@snapshots 0 0

Before, I didn't use leading slashes and mount /snapshots failed. Now mount /snapshot works.

System:

# uname -a
Linux debian-9 4.9.0-8-amd64 #1 SMP Debian 4.9.110-3+deb9u4 (2018-08-21) x86_64 GNU/Linux
# btrfs --version
btrfs-progs v4.7.3
# btrfs subvolume list -up /backup
ID 258 gen 10 parent 5 top level 5 uuid b2740892-9b17-9147-b930-83de797d20df path @
ID 259 gen 8 parent 5 top level 5 uuid 10560ce1-b6f5-1248-94a0-c0a7734b804f path @snapshots

Solution 2

Looks like bug - I've stumbled across a similiar problem: https://unix.stackexchange.com/q/190698/34801

Mounting with subvolid= works.

This should work:

/dev/mapper/fs--1--vg-root /srv            btrfs   defaults,compress=zlib,subvolid=260 0       2

Comments

[Lie Ryan]

Does the subdirectory /srv exists? mount needs the target directory to already exist before the partition/subvolume can be mounted there.

[ThiagoCMC]

So, this might be a BUG. But against which package should I register it at Launchpad.net?

[Lie Ryan]

Why do you seem to be mounting an LVM VG (volume group)? Shouldn't you be mounting an LV (logical volume)? I'm currently not at my workstation that has LVM and BTRFS right now, so I can't check whether the mapper name should look like (/dev/mapper/fs--1--vg-root), but they look odd. If I recall correctly, in my workstation the BTRFS is mounted with the LV's UUID. I believe you can also mount with the /dev/vgblah/lvbleh, but I've never tried mounting it with /dev/mapper. From a quick search, the naming convention used by device mapper for an LV seems to be /dev/mapper/vgblah-lvbleh.

[ThiagoCMC]

Hey Ryan! I've updated the question, I added the /home partition that come from installation, I've used it as an example, and it mounts using /dev/mapper, so, I tried to copy it as an example. Still doesn't work... I'm wondering here... Are you able to mount a BTRFS subvolume created by you after the installation?

[Lie Ryan]

Does that "/dev/mapper/fs--1--vg-root` device file exists? And if it does, what type of file is it? Yes, creating a subvolume after installation wasn't a problem at least in 14.04 where I had similar setup. What's your VG and LV name? Can you try using the /dev/myvgname/mylvname device file name?

[ThiagoCMC]

Ryan, yes, it exists... It was created by Ubuntu itself, automatically, during the installation. Hostname = fs-1, VG = fs-1-vg, LV = root. I'll try to use it with /dev/fs-1-vg/root instead, also, I'll try to use it without LVM, with btrfs directly at HD's partition, to simplify it.

[Lie Ryan]

files in /dev are usually created at boot time or dynamically at run time when devices are plugged. Anyway, try renaming your LVM VG to have no dashes. A quick search on Google seems to show a host of different issues with dashes in the VG or LV name. As to which component this bug should be filed on, that's probably for the developers to decide whether they want to to reject VG names containing dashes during VG creation or to actually fix all components with issues with dash (IMO, the former is more likely).