New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
function btrfs_subvolume_exists fails to properly evaluate some entries #1589
Comments
@OliverO2 |
@WackyOne |
I'll try to come up with a fix. What we're seeing here is just an unexpected (but valid) subvolume structure. A fix would be quite easy if
or like this (at least with the
I'll check if this is still relevant. |
@OliverO2 E.g. see btrfs subvolume list -a ... | sed -e 's/<FS_TREE>\///' because - as far as I remember - when one cuts '<FS_TREE>' away |
You are probably right in assuming that using The problem is that Additionally, on Ubuntu 16.04 LTS, the btrfs-subvolume(8) manual page is out of sync with actual behavior. For the
Actual output looks like:
So we don't have a specific format to really rely on and have to resort to a reasonable guess. |
@OliverO2 ... top-level subvolume, whose subvolume id is 5(FS_TREE) (which is not in my "man btrfs-subvolume" man page). Careful: |
Fix btrfs_subvolume_exists() function to make subvolume match non-ambiguous cf. #1589
With #1591 merged @WackyOne # git log | grep 1591 Merge pull request #1591 from OliverO2/fix/btrfs_subvolume_exists |
@OliverO2 |
@jsmeix Regarding the
|
@OliverO2 It proves that whenever one does something Using any other subvolume below the root subvolume Because when looking at a btrfs filesystem from I think I can reproduce such unexpected The crucial point why "btrfs subvol list -a /" looks strange What I get on SLES12-SP2 (excerpts as needed): # findmnt -t btrfs -o TARGET,SOURCE TARGET SOURCE / /dev/sda2[/@/.snapshots/1/snapshot] ... |-/var/lib/mysql /dev/sda2[/@/var/lib/mysql] |-/var/lib/named /dev/sda2[/@/var/lib/named] |-/var/lib/libvirt/images /dev/sda2[/@/var/lib/libvirt/images] |-/var/lib/mariadb /dev/sda2[/@/var/lib/mariadb] |-/var/lib/mailman /dev/sda2[/@/var/lib/mailman] |-/var/lib/machines /dev/sda2[/@/var/lib/machines] |-/var/lib/pgsql /dev/sda2[/@/var/lib/pgsql] # btrfs subvolume create /var/lib/mystuff Create subvolume '/var/lib/mystuff' # btrfs subvol list -a / | grep var/lib ID 269 gen 760 top level 257 path <FS_TREE>/@/var/lib/libvirt/images ID 270 gen 760 top level 257 path <FS_TREE>/@/var/lib/machines ID 271 gen 760 top level 257 path <FS_TREE>/@/var/lib/mailman ID 272 gen 760 top level 257 path <FS_TREE>/@/var/lib/mariadb ID 273 gen 760 top level 257 path <FS_TREE>/@/var/lib/mysql ID 274 gen 760 top level 257 path <FS_TREE>/@/var/lib/named ID 275 gen 760 top level 257 path <FS_TREE>/@/var/lib/pgsql ID 300 gen 879 top level 259 path @/.snapshots/1/snapshot/var/lib/mystuff # mkdir /tmp/btrfsroot # mount -t btrfs -o subvolid=0 /dev/sda2 /tmp/btrfsroot/ # btrfs subvol list -a /tmp/btrfsroot/ | grep var/lib ID 269 gen 760 top level 257 path <FS_TREE>/@/var/lib/libvirt/images ID 270 gen 760 top level 257 path <FS_TREE>/@/var/lib/machines ID 271 gen 760 top level 257 path <FS_TREE>/@/var/lib/mailman ID 272 gen 760 top level 257 path <FS_TREE>/@/var/lib/mariadb ID 273 gen 760 top level 257 path <FS_TREE>/@/var/lib/mysql ID 274 gen 760 top level 257 path <FS_TREE>/@/var/lib/named ID 275 gen 760 top level 257 path <FS_TREE>/@/var/lib/pgsql ID 300 gen 879 top level 259 path <FS_TREE>/@/.snapshots/1/snapshot/var/lib/mystuff |
@WackyOne You're welcome. Thanks for the bug report and your test feedback! |
@WackyOne |
Relax-and-Recover 2.2-git.0.0.unknown / 2017-10-03
OS_VENDOR=SUSE_LINUX
OS_VERSION=12
Empty (all defaults)
BIOS
There are various ways that subvolumes may appear under the root volume. One example is:
ID 259 gen 6876715 top level 5 path opt
ID 261 gen 6879102 top level 5 path tmp
ID 265 gen 6872990 top level 5 path var/opt
ID 267 gen 6879047 top level 5 path var/tmp
For path 'opt' and for path 'tmp' it matches twice, therefor returning false.
I have no work-around other than changing the function to do a better match.
The text was updated successfully, but these errors were encountered: