#497 Issue closed: SLES12: recovering fails due btrfs subvolume target directory not existing¶
Labels: enhancement, bug, fixed / solved / done
abbbi opened issue at 2014-10-29 10:09:¶
recovering a standard SLES12 installation fails:
Creating btrfs-filesystem / on /dev/sda2
Btrfs v3.16+20140829
See http://btrfs.wiki.kernel.org for
more information.
Turning ON incompat feature 'extref': increased hardlink limit per file to 65536
Turning ON incompat feature 'skinny-metadata': reduced-size metadata extent refs
fs created label (null) on /dev/sda2
nodesize 16384 leafsize 16384 sectorsize 4096 size 17.77GiB
Mounting filesystem /
Creating btrfs-filesystem /.snapshots on /dev/sda2
Mounting filesystem /.snapshots
Create subvolume '/mnt/local/.snapshots'
Creating btrfs-filesystem /var/tmp on /dev/sda2
Mounting filesystem /var/tmp
An error occurred during layout recreation.
looking at the detaile dlogfile:
++++ btrfs filesystem show /dev/sda2
+++ new_uuid=ac7ef7e9-9fd6-45c1-8453-029ff966fcb8
+++ '[' 6dc24dde-008f-48ac-9eda-160f736f05ec '!=' ac7ef7e9-9fd6-45c1-8453-029ff966fcb8 ']'
+++ '[' '!' -f /var/lib/rear/layout/fs_uuid_mapping ']'
+++ grep -q 6dc24dde-008f-48ac-9eda-160f736f05ec /var/lib/rear/layout/fs_uuid_mapping
+++ [[ 0 -eq 0 ]]
++++ tail -1
++++ awk '{print $2}'
++++ grep 6dc24dde-008f-48ac-9eda-160f736f05ec /var/lib/rear/layout/fs_uuid_mapping
+++ old_uuid=ac7ef7e9-9fd6-45c1-8453-029ff966fcb8
+++ SED_SCRIPT=';/6dc24dde-008f-48ac-9eda-160f736f05ec/s/ac7ef7e9-9fd6-45c1-8453-029ff966fcb8/ac7ef7e9-9fd6-45c1-8453-029ff966fcb8/g'
+++ sed -i ';/6dc24dde-008f-48ac-9eda-160f736f05ec/s/ac7ef7e9-9fd6-45c1-8453-029ff966fcb8/ac7ef7e9-9fd6-45c1-8453-029ff966fcb8/g' /var/lib/rear/layout/fs_uuid_mapping
+++ LogPrint 'Mounting filesystem /var/tmp'
+++ Log 'Mounting filesystem /var/tmp'
+++ test 1 -gt 0
++++ Stamp
++++ date '+%Y-%m-%d %H:%M:%S '
+++ echo '2014-10-29 10:11:12 Mounting filesystem /var/tmp'
2014-10-29 10:11:12 Mounting filesystem /var/tmp
+++ Print 'Mounting filesystem /var/tmp'
+++ test 1
+++ echo -e 'Mounting filesystem /var/tmp'
+++ btrfs subvolume create /mnt/local/var/tmp
ERROR: can't access '/mnt/local/var'
2014-10-29 10:11:12 An error occurred during layout recreation.
indeed /mnt/local/var does not exist on the target volume. This is the
original filesystem layout of the system the backup was created from
(basically a standard SLES12 installation)
linux-60x9:~ # mount
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
devtmpfs on /dev type devtmpfs (rw,nosuid,size=1285608k,nr_inodes=321402,mode=755)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
tmpfs on /sys/fs/cgroup type tmpfs (rw,nosuid,nodev,noexec,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpuacct,cpu)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event)
cgroup on /sys/fs/cgroup/hugetlb type cgroup (rw,nosuid,nodev,noexec,relatime,hugetlb)
/dev/sda2 on / type btrfs (rw,relatime,space_cache)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=28,pgrp=1,timeout=300,minproto=5,maxproto=5,direct)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime)
mqueue on /dev/mqueue type mqueue (rw,relatime)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
/dev/sda2 on /.snapshots type btrfs (rw,relatime,space_cache)
/dev/sda2 on /var/tmp type btrfs (rw,relatime,space_cache)
/dev/sda2 on /var/opt type btrfs (rw,relatime,space_cache)
/dev/sda2 on /var/spool type btrfs (rw,relatime,space_cache)
/dev/sda2 on /var/log type btrfs (rw,relatime,space_cache)
/dev/sda2 on /var/lib/pgsql type btrfs (rw,relatime,space_cache)
/dev/sda2 on /var/lib/named type btrfs (rw,relatime,space_cache)
/dev/sda2 on /var/lib/mailman type btrfs (rw,relatime,space_cache)
/dev/sda2 on /boot/grub2/x86_64-efi type btrfs (rw,relatime,space_cache)
/dev/sda2 on /var/crash type btrfs (rw,relatime,space_cache)
/dev/sda2 on /usr/local type btrfs (rw,relatime,space_cache)
/dev/sda2 on /tmp type btrfs (rw,relatime,space_cache)
/dev/sda2 on /srv type btrfs (rw,relatime,space_cache)
/dev/sda2 on /opt type btrfs (rw,relatime,space_cache)
/dev/sda2 on /boot/grub2/i386-pc type btrfs (rw,relatime,space_cache)
/dev/sda3 on /home type xfs (rw,relatime,attr2,inode64,noquota)
abbbi commented at 2014-10-29 10:31:¶
hi,
on a closer look im missing the mount command with the subvol ID after creating the subvolume vor var/tmp/, doing it this way on the command line:
rear> btrfs subvolume list /mnt/local/var/tmp/
ID 257 gen 10 top level 5 path .snapshots
ID 259 gen 11 top level 5 path var/tmp
rear> mount -o subvolid=259 /dev/sda2 /mnt/local/var/tmp/
works out.
also creating the next volume works out just fine:
rear> btrfs subvolume create /mnt/local/var/spool
Create subvolume '/mnt/local/var/spool'
rear> btrfs_id=$(btrfs subvolume list /mnt/local/var/spool | tail -1 | awk '{print $2}')
rear> mountopts=" -o subvolid=${btrfs_id}"
rear> mount$mountopts /dev/sda2 /mnt/local/var/spool
could this be some kind of timing issue?
gdha commented at 2014-10-29 12:54:¶
Nor rear 1.16.1 nor the github version of rear support currently the
btrfs filesystem on SLES12.
However, in the meantime ('till support has been added and tested into
the mainstream track of rear) you could use
https://build.opensuse.org/package/show/home:jsmeix/rear116
version of SuSe. However, bear in mind, if you have problems with
rear116 version do not submit an issue with the original rear
maintainers as you're using a fork of rear.
jsmeix commented at 2014-11-13 11:35:¶
The RPM package rear116 from my openSUSE build service home project home:jsmeix contains a SLE12-btrfs-example.conf file (that gets installed as /usr/share/rear/conf/SLE12-btrfs-example.conf). Use this as starting point for your /etc/rear/local.conf file. Furthermore regarding btrfs in general and the sophisticated btrfs structure on SLE12 see https://en.opensuse.org/SDB:Disaster_Recovery there in particular the "Fundamentals about Relax-and-Recover presentation PDF".
gdha commented at 2014-12-02 15:21:¶
related to BTRFS issues #233 and #408
jsmeix commented at 2014-12-08 14:43:¶
I think that I could change my adaptions and enhancements for the sophisticated btrfs structure on SLE12 in
https://build.opensuse.org/package/view_file/home:jsmeix/rear116/adaptions_for_btrfs_for_SLE12.diff
into something that works generically for any btrfs structure.
As far as I see the only thing that I used which makes my current adaptions_for_btrfs_for_SLE12.diff specific for SLE12 is that I used the SLE12 btrfs default subvolume name '/@' in a hardcoded way.
If I could change it to deal with the btrfs default subvolume in a generic way, I hope it could work for any btrfs structure.
I think there is nothing really special regarding btrfs on SLE12. I assume such kind of sophisticated btrfs structure as on SLE12 could be also created with any other recent Linux distribution.
Therefore I think it would not work well when for each Linux distribution there is separated code that deals with btrfs.
When time permits I will try to change my current btrfs stuff for SLE12 into a more generic way how to deal with btrfs.
But first of all there is Christmas time... ;-)
schlomo commented at 2014-12-08 14:56:¶
Hi Johannes,
thanks a lot - I think that you really know a lot about btrfs. Maybe
you
can make the SUSE-style subvolume structure optional - and the /@ part
configurable? That way also simple btrfs setups would work.
Kind Regards,
Schlomo
On 8 December 2014 at 15:43, Johannes Meixner
notifications@github.com
wrote:
I think that I could change my adaptions and enhancements for the
sophisticated btrfs structure on SLE12 inhttps://build.opensuse.org/package/view_file/home:jsmeix/rear116/adaptions_for_btrfs_for_SLE12.diff
into something that works generically for any btrfs structure.
As far as I see the only thing that I used which makes my current
adaptions_for_btrfs_for_SLE12.diff specific for SLE12 is that I used the
SLE12 btrfs default subvolume name '/@' in a hardcoded way.If I could change it to deal with the btrfs default subvolume in a generic
way, I hope it could work for any btrfs structure.I think there is nothing really special regarding btrfs on SLE12. I assume
such kind of sophisticated btrfs structure as on SLE12 could be also
created with any other recent Linux distribution.Therefore I think it would not work well when for each Linux distribution
there is separated code that deals with btrfs.When time permits I will try to change my current btrfs stuff for SLE12
into a more generic way how to deal with btrfs.But first of all there is Christmas time... ;-)
—
Reply to this email directly or view it on GitHub
https://github.com/rear/rear/issues/497#issuecomment-66124515.
jsmeix commented at 2014-12-08 14:58:¶
FYI:
On SLE12 we have:
# findmnt -t btrfs | cut -b-61 TARGET SOURCE / /dev/sda2[/@] |-/.snapshots /dev/sda2[/@/.snapshots] |-/var/spool /dev/sda2[/@/var/spool] |-/var/tmp /dev/sda2[/@/var/tmp] |-/var/lib/named /dev/sda2[/@/var/lib/named] |-/var/opt /dev/sda2[/@/var/opt] |-/usr/local /dev/sda2[/@/usr/local] |-/tmp /dev/sda2[/@/tmp] |-/var/lib/pgsql /dev/sda2[/@/var/lib/pgsql] |-/home /dev/sda2[/@/home] |-/var/crash /dev/sda2[/@/var/crash] |-/opt /dev/sda2[/@/opt] |-/var/log /dev/sda2[/@/var/log] |-/boot/grub2/i386-pc /dev/sda2[/@/boot/grub2/i386-pc] |-/var/lib/mailman /dev/sda2[/@/var/lib/mailman] |-/srv /dev/sda2[/@/srv] `-/boot/grub2/x86_64-efi /dev/sda2[/@/boot/grub2/x86_64-efi] # btrfs subvolume get-default / ID 257 gen 2260 top level 5 path @
On openSUSE 13.2 we have
# findmnt -t btrfs | cut -b-59 TARGET SOURCE / /dev/sda2 |-/.snapshots /dev/sda2[/.snapshots] |-/var/spool /dev/sda2[/var/spool] |-/var/tmp /dev/sda2[/var/tmp] |-/var/log /dev/sda2[/var/log] |-/var/opt /dev/sda2[/var/opt] |-/var/lib/mailman /dev/sda2[/var/lib/mailman] |-/var/crash /dev/sda2[/var/crash] |-/var/lib/named /dev/sda2[/var/lib/named] |-/var/lib/pgsql /dev/sda2[/var/lib/pgsql] |-/opt /dev/sda2[/opt] |-/tmp /dev/sda2[/tmp] |-/usr/local /dev/sda2[/usr/local] |-/boot/grub2/i386-pc /dev/sda2[/boot/grub2/i386-pc] |-/srv /dev/sda2[/srv] `-/boot/grub2/x86_64-efi /dev/sda2[/boot/grub2/x86_64-efi] # btrfs subvolume get-default / ID 5 (FS_TREE)
gdha commented at 2014-12-08 14:58:¶
Also have a look at issue #233 as I've taken out the mount part
(containing the btrfs specific points) out of the
usr/share/rear/layout/prepare/GNU/Linux/13_include_filesystem_code.sh
script and moved it into
layout/prepare/GNU/Linux/13_include_mount_filesystem_code.sh
jsmeix commented at 2014-12-08 15:07:¶
The /@ part does not need to be configurable.
The '/@' is just the default btrfs subvolume. Any btrfs has a default subvolume - the one that gets mounted by default when no subvolume is specified when mounting a btrfs. Usually the default subvolume is the btrfs root (called "FS_TREE" by btrfs).
I think (and hope) that all I need is generic support for any btrfs default subvolume.
Because openSUSE 13.2 has the usual btrfs subvolume, my current adaptions_for_btrfs_for_SLE12.diff cannot work there which is a good reason for me to clean it up so that is also works on openSUSE.
FYI:
Yes - unfortunately I had to learn something about btrfs the hard way -
by trial and error :-( which means I am not a real btrfs expert - only
one who had learned something about it...
jsmeix commented at 2014-12-08 15:21:¶
I submitted
https://bugzilla.opensuse.org/show_bug.cgi?id=908854
"rear116 cannot work for btrfs on openSUSE (no '/@' in contrast to
SLE12)"
gdha commented at 2014-12-08 15:22:¶
I propose that we post-pone rear-1.17 until end of January 2015 so to give @jsmeix time to create a pull request?
jsmeix commented at 2014-12-08 15:34:¶
Gratien,
I cannot estimate when I have time for it - any customer issues always come first (in particular any printing issues - my main working area).
Therefore do not wait for me. Just release when it can be released.
My personal gut feeling is that it will take a longer time until btrfs is really well supported.
FYI:
btrfs subvolumes can be nested:
E.g. on openSUSE 13.2:
# btrfs subvolume create /usr/local/mysubsubvolume Create subvolume '/usr/local/mysubsubvolume' # btrfs subvolume create /usr/local/mysubsubvolume/mysubsubsubvolume Create subvolume '/usr/local/mysubsubvolume/mysubsubsubvolume' # btrfs subvolume list -a / | grep 'usr/local' ID 262 gen 4146 top level 5 path usr/local ID 315 gen 4152 top level 262 path/usr/local/mysubsubvolume ID 317 gen 4152 top level 315 path /usr/local/mysubsubvolume/mysubsubsubvolume
As far as I know my current adaptions_for_btrfs_for_SLE12.diff even supports nested subvolumes which means the higher-level subvolumes must be created first, then the nested subvolumes...
jsmeix commented at 2014-12-08 15:44:¶
And subvolumes can be mounted anywhere:
Continuing on openSUSE 13.2:
# mkdir /tmp/mysubsubvolume # mount -t btrfs -o subvolid=315 /dev/sda2 /tmp/mysubsubvolume # mkdir /tmp/mysubsubsubvolume # mount -t btrfs -o subvolid=317 /dev/sda2 /tmp/mysubsubsubvolume # findmnt -t btrfs | cut -b-82 | grep 'usr/local' | |-/tmp/mysubsubvolume /dev/sda2[/usr/local/mysubsubvolume] | `-/tmp/mysubsubsubvolume /dev/sda2[/usr/local/mysubsubvolume/mysubsubsubvolume] |-/usr/local /dev/sda2[/usr/local] # echo mysubsubvolume >/usr/local/mysubsubvolume/echo.mysubsubvolume # cat /tmp/mysubsubvolume/echo.mysubsubvolume mysubsubvolume # echo mysubsubsubvolume >/usr/local/mysubsubvolume/mysubsubsubvolume/echo.mysubsubsubvolume # cat /tmp/mysubsubvolume/mysubsubsubvolume/echo.mysubsubsubvolume mysubsubsubvolume
Have Fun!
jsmeix commented at 2014-12-10 12:14:¶
Interestingly my current adaptions_for_btrfs_for_SLE12.diff even works correctly for nested subvolumes that are not mounted:
On the original SLES12 system a /usr/local/mysubsubvol is created (it is nested in the /usr/local subvolume) but it is not mounted:
# btrfs subvolume create /usr/local/mysubsubvol Create subvolume '/usr/local/mysubsubvol' # echo mysubsubvol >/usr/local/mysubsubvol/mysubsubvol.echo # ls /usr/local/mysubsubvol/ mysubsubvol.echo ls /usr/local/ bin games include lib lib64 man mysubsubvol sbin share src f224:~ # btrfs subvolume list -a / ID 257 gen 2797 top level 5 path/@ ID 258 gen 2751 top level 257 path @/boot/grub2/i386-pc ID 259 gen 2751 top level 257 path @/boot/grub2/x86_64-efi ID 260 gen 2751 top level 257 path @/home ID 261 gen 2748 top level 257 path @/opt ID 262 gen 2751 top level 257 path @/srv ID 263 gen 2785 top level 257 path @/tmp ID 264 gen 2800 top level 257 path @/usr/local ID 265 gen 2751 top level 257 path @/var/crash ID 266 gen 2751 top level 257 path @/var/lib/mailman ID 267 gen 2751 top level 257 path @/var/lib/named ID 268 gen 2751 top level 257 path @/var/lib/pgsql ID 269 gen 2797 top level 257 path @/var/log ID 270 gen 2751 top level 257 path @/var/opt ID 271 gen 2800 top level 257 path @/var/spool ID 272 gen 2767 top level 257 path @/var/tmp ID 275 gen 2751 top level 257 path @/.snapshots ID 279 gen 131 top level 275 path /@/.snapshots/1/snapshot ID 280 gen 132 top level 275 path /@/.snapshots/2/snapshot ... ID 293 gen 2800 top level 264 path /@/usr/local/mysubsubvol # grep -v '^#' /etc/rear/local.conf | fold -s -w60 OUTPUT=ISO BACKUP=NETFS BACKUP_OPTIONS="nfsvers=3,nolock" BACKUP_URL=nfs://10.160.4.255/nfs/rearBackups NETFS_KEEP_OLD_BACKUP_COPY=yes BACKUP_PROG_INCLUDE=( '/home/*' '/var/tmp/*' '/var/spool/*' '/var/opt/*' '/var/log/*' '/var/lib/pgsql/*' '/var/lib/mailman/*' '/var/lib/named/*' '/usr/local/*' '/tmp/*' '/srv/*' '/boot/grub2/x86_64-efi/*' '/opt/*' '/boot/grub2/i386-pc/*' ) EXCLUDE_RECREATE=( "${EXCLUDE_RECREATE[@]}" "fs:/home" "fs:/.snapshots" "fs:/var/tmp" "fs:/var/spool" "fs:/var/opt" "fs:/var/log" "fs:/var/lib/pgsql" "fs:/var/lib/mailman" "fs:/var/lib/named" "fs:/usr/local" "fs:/tmp" "fs:/srv" "fs:/var/crash" "fs:/boot/grub2/x86_64-efi" "fs:/opt" "fs:/boot/grub2/i386-pc" ) SSH_ROOT_PASSWORD="rear" USE_DHCLIENT="yes" # rear -d -D mkbackup ... # cat /tmp/rear.2LIwzXJYA5C09cz/rootfs/var/lib/rear/layout/disklayout.conf disk /dev/sda 21474836480 msdos part /dev/sda 1569718272 1048576 primary none /dev/sda1 part /dev/sda 19904069632 1570766848 primary boot /dev/sda2 fs /dev/sda2 / btrfs uuid=5e34f834-0782-4ab9-827b-a03441cd55f0 label= options=rw,relatime,space_cache,normalsubvolumes=/boot/grub2/i38-pc; /boot/grub2/x86_64-efi;/home;/opt;/srv;/tmp;/usr/local;/var/crash; /var/lib/mailman;/var/lib/named;/var/lib/pgsql;/var/log;/var/opt; /var/spool;/var/tmp;/.snapshots;/usr/local/mysubsubvol #fs /dev/sda2 /.snapshots btrfs ... #fs /dev/sda2 /var/tmp btrfs ... #fs /dev/sda2 /var/spool btrfs ... #fs /dev/sda2 /var/opt btrfs ... #fs /dev/sda2 /var/lib/mailman btrfs ... #fs /dev/sda2 /var/lib/pgsql btrfs ... #fs /dev/sda2 /var/log btrfs ... #fs /dev/sda2 /var/lib/named btrfs ... #fs /dev/sda2 /usr/local btrfs ... #fs /dev/sda2 /var/crash btrfs ... #fs /dev/sda2 /srv btrfs ... #fs /dev/sda2 /home btrfs ... #fs /dev/sda2 /boot/grub2/x86_64-efi btrfs ... #fs /dev/sda2 /tmp btrfs ... #fs /dev/sda2 /opt btrfs ... #fs /dev/sda2 /boot/grub2/i386-pc btrfs ... swap /dev/sda1 uuid=55efb538-549b-44cc-b622-42dc98d37074 label=
In the disklayout.conf output above the long first btrfs line is folded and the other disabled btrfs lines are cut.
During "rear recover" the "mysubsubvol" will be created and mounted in the rear recovery system because my current adaptions_for_btrfs_for_SLE12.diff mounts every subvolume:
# btrfs subvolume list -a /mnt/local ID 257 gen 28 top level 5 path/@ ID 258 gen 9 top level 257 path @/.snapshots ID 259 gen 26 top level 257 path @/boot/grub2/i386-pc ID 260 gen 26 top level 257 path @/boot/grub2/x86_64-efi ID 261 gen 26 top level 257 path @/home ID 262 gen 26 top level 257 path @/opt ID 263 gen 26 top level 257 path @/srv ID 264 gen 26 top level 257 path @/tmp ID 265 gen 26 top level 257 path @/usr/local ID 266 gen 26 top level 265 path /@/usr/local/mysubsubvol ID 267 gen 18 top level 257 path @/var/crash ID 268 gen 19 top level 257 path @/var/lib/mailman ID 269 gen 20 top level 257 path @/var/lib/named ID 270 gen 21 top level 257 path @/var/lib/pgsql ID 271 gen 26 top level 257 path @/var/log ID 272 gen 23 top level 257 path @/var/opt ID 273 gen 26 top level 257 path @/var/spool ID 274 gen 25 top level 257 path @/var/tmp # mount | grep btrfs /dev/sda2 on /mnt/local type btrfs (rw,relatime,space_cache) /dev/sda2 on /mnt/local/.snapshots type btrfs (rw,relatime,space_cache) /dev/sda2 on /mnt/local/boot/grub2/i386-pc type btrfs (rw,relatime,space_cache) /dev/sda2 on /mnt/local/boot/grub2/x86_64-efi type btrfs (rw,relatime,space_cache) /dev/sda2 on /mnt/local/home type btrfs (rw,relatime,space_cache) /dev/sda2 on /mnt/local/opt type btrfs (rw,relatime,space_cache) /dev/sda2 on /mnt/local/srv type btrfs (rw,relatime,space_cache) /dev/sda2 on /mnt/local/tmp type btrfs (rw,relatime,space_cache) /dev/sda2 on /mnt/local/usr/local type btrfs (rw,relatime,space_cache) /dev/sda2 on /mnt/local/usr/local/mysubsubvol type btrfs (rw,relatime,space_cache) /dev/sda2 on /mnt/local/var/crash type btrfs (rw,relatime,space_cache) /dev/sda2 on /mnt/local/var/lib/mailman type btrfs (rw,relatime,space_cache) /dev/sda2 on /mnt/local/var/lib/named type btrfs (rw,relatime,space_cache) /dev/sda2 on /mnt/local/var/lib/pgsql type btrfs (rw,relatime,space_cache) /dev/sda2 on /mnt/local/var/log type btrfs (rw,relatime,space_cache) /dev/sda2 on /mnt/local/var/opt type btrfs (rw,relatime,space_cache) /dev/sda2 on /mnt/local/var/spool type btrfs (rw,relatime,space_cache) /dev/sda2 on /mnt/local/var/tmp type btrfs (rw,relatime,space_cache)
Currently I don't know if it also works when not all subvolumes are mounted in the rear recovery system. Perhaps all subvolumes must be mounted so that the files can be restored there.
After rebooting in the recovered system it is no longer mounted:
# btrfs subvolume list -a / ID 257 gen 35 top level 5 path/@ ID 258 gen 34 top level 257 path @/.snapshots ID 259 gen 34 top level 257 path @/boot/grub2/i386-pc ID 260 gen 34 top level 257 path @/boot/grub2/x86_64-efi ID 261 gen 35 top level 257 path @/home ID 262 gen 30 top level 257 path @/opt ID 263 gen 34 top level 257 path @/srv ID 264 gen 34 top level 257 path @/tmp ID 265 gen 34 top level 257 path @/usr/local ID 266 gen 26 top level 265 path /@/usr/local/mysubsubvol ID 267 gen 34 top level 257 path @/var/crash ID 268 gen 34 top level 257 path @/var/lib/mailman ID 269 gen 34 top level 257 path @/var/lib/named ID 270 gen 34 top level 257 path @/var/lib/pgsql ID 271 gen 35 top level 257 path @/var/log ID 272 gen 34 top level 257 path @/var/opt ID 273 gen 34 top level 257 path @/var/spool ID 274 gen 34 top level 257 path @/var/tmp # findmnt -at btrfs | cut -b-61 TARGET SOURCE / /dev/sda2[/@] |-/var/tmp /dev/sda2[/@/var/tmp] |-/var/spool /dev/sda2[/@/var/spool] |-/.snapshots /dev/sda2[/@/.snapshots] |-/var/lib/named /dev/sda2[/@/var/lib/named] |-/var/opt /dev/sda2[/@/var/opt] |-/opt /dev/sda2[/@/opt] |-/home /dev/sda2[/@/home] |-/boot/grub2/i386-pc /dev/sda2[/@/boot/grub2/i386-pc] |-/var/log /dev/sda2[/@/var/log] |-/srv /dev/sda2[/@/srv] |-/var/lib/pgsql /dev/sda2[/@/var/lib/pgsql] |-/boot/grub2/x86_64-efi /dev/sda2[/@/boot/grub2/x86_64-efi] |-/usr/local /dev/sda2[/@/usr/local] |-/var/crash /dev/sda2[/@/var/crash] |-/tmp /dev/sda2[/@/tmp] `-/var/lib/mailman /dev/sda2[/@/var/lib/mailman] # ls /usr/local/mysubsubvol/ mysubsubvol.echo # cat /usr/local/mysubsubvol/mysubsubvol.echo mysubsubvol # ls /usr/local/ bin games include lib lib64 man mysubsubvol sbin share src
The subvolume IDs are different in the recreated system but this should be o.k. because the btrfs subvolume structure is the same - except there are admins who use the subvolume ID in selfmade scripts or programs that store subvolume IDs somewhere.
The above example shows that I cannot keep the subvolume IDs in gerenal because I cannot recreate the snapshot subvolumes so that the ID of the in the original system late created mysubsubvol cannot be the same in the recovered systems where mysubsubvol is created at system install time.
But I could perhaps keep the subvol IDs of those subvols that are created during system install time of the original system to mitigate possibly unexpected bad side-effects when subvol IDs are different in the recreated system.
jsmeix commented at 2014-12-10 12:51:¶
Gratien, Schlomo,
the more I think about it how to cleanly implememt it the more I would like to really clean it up by introducing a new type of component called "btrfs" or "btrfssubvol" in the disklayout.conf file.
Reason:
A current "fs /dev/sda2 / btrfs ..." entry in disklayout.conf has the "fs"="filesystem" component type and that means in compliance with all other "fs" entries a whole btrfs filesystem and not a subvolume of a btrfs filesystem.
In my opinion mixing up whole filesystems with parts of whole filesystems (a.k.a. subvolumes in case of btrfs) in one same component type "fs" leads to an endless mess of awkward workaround-like code that nobody understands and nobody can maintain (of course except the one magician who made such code ;-)
If you agree to introduce a new component type to deal with btrfs subvolumes, I would like to get some general advice from you, how I should make it - in particular what scripts I should first and foremost adapt when implementing it.
jsmeix commented at 2014-12-10 13:05:¶
By the way:
I am missing a component type "mount" that tells what is mounted where. I think the current assumption that each component type "fs" has a mountpoint is not always true.
If there would be a new component type for btrfs subvolumes, that would also need mountpoints for the mounted subvolumes which means there are at least two component types where mountpoints are defined which makes it more complicated to see what is mounted where.
I think it would be cleaner to have separated things in separated component types - something like:
"part" only for creating partitions
"fs" only for creating filesystems
"btrfssubvol" only for creating btrfs subvolumes
"mount" only for creating mountpoints and mount stuff there
What do you think?
gdha commented at 2014-12-10 13:56:¶
@jsmeix @abbbi @rear/owners The script
/usr/share/rear/layout/save/GNU/Linux/23_filesystem_layout.sh is the
first part that needs to be fixed as it read it input from the mount
command.
As far as I can remember fs was always referring to a mounted file
system, which in case of btrfs is not required anymore(?). I'm afraid
I'm a btrfs novice (for the moment) so I'm a bit confused (which is
normal in my case :)
However, besides that I think btrfssubvol component might be a good
way to proceed. Around the mount component I need advise from our rear
maintainers.
jsmeix commented at 2014-12-11 10:37:¶
After sleeping on it I think what I will try to implement is:
I will keep the "fs" component type as is also for btrfs and have all what belongs to btrfs subvolumes in a separated component type "btrfssubvol" with sub-types "defaultsubvol", "snapshotsubvol", and "normalsubvol"or I may even use separated comonent types "btrfsdefaultsubvol", "btrfssnapshotsubvol", and "btrfsnormalsubvol".
This should result the following clean and fail-safe behaviour:
A "fs" component type for btrfs would only create the btrfs filesystem
and its mountpoint "mp" parameter would mount the whole btrfs filesystem
(i.e. the btrfs root subvolume) there by using the mount option "-o
subvolid=0".
For this I must make sure that only one "fs" component will be created
for each whole btrfs filesystem (i.e. no longer "fs" components for
btrfs subvolumes).
This way users who use plain btrfs without any kind of special subvolume (i.e. on their btrfs the btrfs default subvolume is the same as the btrfs root subvolume which is the btrfs filesystem root and they do not have any other subvolume) only get a "fs" component type for btrfs which is in full compliance with any other "fs" component type (e.g. for the ext* filesystems).
Any special btrfs subvolume stuff is specified via "btrfs*" component type(s).
For example if the user has a special btrfs default subvolume that is not the btrfs root subvolume, then the default subvolume would be created (the btrfs root subvolume is already mounted, see above) and the btrfs filesystem would be re-mounted so that the default subvolume gets mounted at a mountpoint that is specified in the "btrfs*" component (which could be the same or a different mountpoint than what is specified in the "fs" component) so that the backup restore would fill in the fils at the right place in the mounted filesystem tree.
When a user uses btrfs with special btrfs subvolume stuff in his original system but he disables the "btrfs*" components in his disklayout.conf file, then he should get in the recreated system a plain btrfs mounted at the mountpoint specified by the "mp" parameter (usually this would be '/') and even the backup restore would "just work" because the paths in backup.tar.gz do not "know" something about btrfs subvolumes.
In the end what I like to get is "KSSS" (one more 'S' instead of the
'I'):
"Keep Separated Stuff Separated" ;-)
jsmeix commented at 2014-12-11 10:42:¶
Perhaps even KSSSS:
"Keep Separated Stuff Safely Separated"?
;-))
jsmeix commented at 2014-12-11 11:04:¶
In the original system I need to find out the "real reality" about an existing btrfs to be able to re-create it.
I think that I will have to mount the btrfs root subvolume
to be able to find out the "real reality" about a btrfs.
I think in the original system I will do something like the following that I did on SLES12:
First run findmnt to get what is mounted where.
Then mount the btrfs root subvolume to get the "real reality" of the whole btrfs via that mount point.
# findmnt -at btrfs | cut -b-61 TARGET SOURCE / /dev/sda2[/@] |-/.snapshots /dev/sda2[/@/.snapshots] |-/var/opt /dev/sda2[/@/var/opt] |-/var/tmp /dev/sda2[/@/var/tmp] |-/var/lib/pgsql /dev/sda2[/@/var/lib/pgsql] |-/var/spool /dev/sda2[/@/var/spool] |-/var/lib/named /dev/sda2[/@/var/lib/named] |-/opt /dev/sda2[/@/opt] |-/var/lib/mailman /dev/sda2[/@/var/lib/mailman] |-/var/log /dev/sda2[/@/var/log] |-/boot/grub2/i386-pc /dev/sda2[/@/boot/grub2/i386-pc] |-/usr/local /dev/sda2[/@/usr/local] |-/tmp /dev/sda2[/@/tmp] |-/var/crash /dev/sda2[/@/var/crash] |-/srv /dev/sda2[/@/srv] |-/boot/grub2/x86_64-efi /dev/sda2[/@/boot/grub2/x86_64-efi] `-/home /dev/sda2[/@/home] # mktemp -d /tmp/btrfsroot.XXXXXXXXXX /tmp/btrfsroot.WxMLpNnSXx # mount -t btrfs -o subvolid=0 /dev/sda2 /tmp/btrfsroot.WxMLpNnSXx # btrfs subvolume get-default /tmp/btrfsroot.WxMLpNnSXx ID 257 gen 3146 top level 5 path @ # btrfs subvolume list -a /tmp/btrfsroot.WxMLpNnSXx ID 257 gen 3145 top level 5 path @ ID 258 gen 2810 top level 257 path/@/boot/grub2/i386-pc ID 259 gen 2751 top level 257 path /@/boot/grub2/x86_64-efi ID 260 gen 3018 top level 257 path /@/home ID 261 gen 2969 top level 257 path /@/opt ID 262 gen 2813 top level 257 path /@/srv ID 263 gen 3145 top level 257 path /@/tmp ID 264 gen 3144 top level 257 path /@/usr/local ID 265 gen 2751 top level 257 path /@/var/crash ID 266 gen 2751 top level 257 path /@/var/lib/mailman ID 267 gen 2751 top level 257 path /@/var/lib/named ID 268 gen 2751 top level 257 path /@/var/lib/pgsql ID 269 gen 3138 top level 257 path /@/var/log ID 270 gen 2751 top level 257 path /@/var/opt ID 271 gen 3144 top level 257 path /@/var/spool ID 272 gen 3032 top level 257 path /@/var/tmp ID 275 gen 2979 top level 257 path /@/.snapshots ID 279 gen 131 top level 275 path /@/.snapshots/1/snapshot ID 280 gen 132 top level 275 path /@/.snapshots/2/snapshot # btrfs subvolume list -as /tmp/btrfsroot.WxMLpNnSXx ID 279 gen 131 cgen 131 top level 275 otime 2014-11-03 13:22:34 path /@/.snapshots/1/snapshot ID 280 gen 132 cgen 132 top level 275 otime 2014-11-03 13:22:54 path /@/.snapshots/2/snapshot
pavoldomin commented at 2014-12-11 12:48:¶
Hi,
- Why findmnt, not just normal mount or
/proc/mounts? For example SLES11 util-linux does not seem to contain findmnt. - Why mount it again, when it is already mounted?
In the following setup (its actually sles11sp3) we have one btrfs
filesystem, mounted at / and its subvolume /osbackup is mounted at
/hana/osbackup, (i.e. its visible in two places, /osbackup and
/hana/osbackup)
#grep btrfs /proc/mounts
/dev/sda4 / btrfs rw,relatime,space_cache 0 0
/dev/sda4 /hana/osbackup btrfs rw,relatime,space_cache 0 0
#btrfs subvolume get-default /
ID 256 gen 273280 top level 5 path @
#btrfs subvolume get-default /hana/osbackup
ID 256 gen 273280 top level 5 path @
#btrfs subvolume list -a /
ID 256 gen 273281 top level 5 path <FS_TREE>/@
ID 258 gen 273020 top level 5 path <FS_TREE>/@/srv
ID 259 gen 273218 top level 5 path <FS_TREE>/@/opt
ID 260 gen 273281 top level 5 path <FS_TREE>/@/tmp
ID 261 gen 273020 top level 5 path <FS_TREE>/@/osbackup
ID 262 gen 273281 top level 5 path <FS_TREE>/@/var
ID 263 gen 273281 top level 5 path <FS_TREE>/@/var/spool
ID 264 gen 273281 top level 5 path <FS_TREE>/@/var/run
ID 265 gen 273281 top level 5 path <FS_TREE>/@/var/log
ID 266 gen 273056 top level 5 path <FS_TREE>/@/var/tmp
ID 267 gen 271655 top level 5 path <FS_TREE>/@/var/crash
ID 276 gen 28 top level 5 path <FS_TREE>/@/origin_tmp
ID 277 gen 29 top level 5 path <FS_TREE>/@/origin
ID 278 gen 273247 top level 5 path <FS_TREE>/@/.snapshots
ID 279 gen 1485 top level 5 path <FS_TREE>/@/.snapshots/1/snapshot
ID 415 gen 16463 top level 5 path <FS_TREE>/@/.snapshots/136/snapshot
#btrfs subvolume list -as /
ID 276 gen 28 cgen 28 top level 5 otime 2014-08-25 16:06:07 path <FS_TREE>/@/origin_tmp
ID 277 gen 29 cgen 29 top level 5 otime 2014-08-25 16:06:07 path <FS_TREE>/@/origin
ID 279 gen 1485 cgen 1485 top level 5 otime 2014-08-26 14:00:01 path <FS_TREE>/@/.snapshots/1/snapshot
ID 415 gen 16463 cgen 16463 top level 5 otime 2014-09-01 05:00:01 path <FS_TREE>/@/.snapshots/136/snapshot
I
jsmeix commented at 2014-12-11 13:02:¶
pavoldomin,
just tell me how normal mount shows what btrfs subvolume is mounted where.
Preferably provide a diff (e.g. for 23_filesystem_layout.sh or whatever files you changed in your particular case) that "does the right thing" in your case so that I can see what you actually did to make it work in your particular case.
FYI on my SLES12:
# man 8 mount The listing. The listing mode is maintained for backward compatibility only. For more robust and customizable output use findmnt(8), especially in your scripts.
Of coure I will be backward compatible as far as possible but this may mean that I cannot correctly detect what btrfs subvolume is mounted where. Therefore I will use findmnt when it is available.
pavoldomin commented at 2014-12-11 13:16:¶
oh, ok, so you can actually have even the root btrfs volume magically auto-mounted without /proc/mounts entry? My problem with temporary mounts to check anything is, that they often tend to be difficult to umount than (some process likes to open them). But if there is no other way, well..
jsmeix commented at 2014-12-11 14:38:¶
I really do not like mounting btrfs when "rear mkbackup" is run because it changes the original system (mounting is much more than only read something from the running system).
I really appreciate any better way how to get that information out of a btrfs that can be more or less arbitrarily mounted from my current point of view.
On the other hand "rear mkbackup" mounts already something (e.g. the NFS share whereto a backup can be stored) so that having additinoal stuff munted while "rear mkbackup" runs is not a totally new thing.
I should mount the btrfs root subvolume read-only to be more on the safe side.
pavoldomin,
many thanks for your comment - at least it made me thinking a bit more
about how to mount something safely (the third 'S' in KSSSS ;-) when it
is only to read some information!
jsmeix commented at 2014-12-11 15:34:¶
It seems it is not possible to mount the btrfs root subvolume read-only (perhaps because it is already mounted otherwise read-write?).
On my SLES12 system:
# mount -t btrfs -o ro -o subvolid=0 /dev/sda2 /tmp/btrfsroot && echo ok || echo failed
mount: /dev/sda2 is already mounted or /tmp/btrfsroot busy
/dev/sda2 is already mounted on /
/dev/sda2 is already mounted on /var/tmp
/dev/sda2 is already mounted on /.snapshots
/dev/sda2 is already mounted on /var/spool
/dev/sda2 is already mounted on /var/opt
/dev/sda2 is already mounted on /var/log
/dev/sda2 is already mounted on /var/lib/pgsql
/dev/sda2 is already mounted on /var/lib/named
/dev/sda2 is already mounted on /usr/local
/dev/sda2 is already mounted on /var/crash
/dev/sda2 is already mounted on /var/lib/mailman
/dev/sda2 is already mounted on /srv
/dev/sda2 is already mounted on /opt
/dev/sda2 is already mounted on /tmp
/dev/sda2 is already mounted on /home
/dev/sda2 is already mounted on /boot/grub2/x86_64-efi
/dev/sda2 is already mounted on /boot/grub2/i386-pc
failed
# findmnt -at btrfs | cut -b-61
TARGET SOURCE
/ /dev/sda2[/@]
|-/var/tmp /dev/sda2[/@/var/tmp]
|-/var/spool /dev/sda2[/@/var/spool]
|-/.snapshots /dev/sda2[/@/.snapshots]
|-/var/lib/pgsql /dev/sda2[/@/var/lib/pgsql]
|-/var/opt /dev/sda2[/@/var/opt]
|-/var/lib/named /dev/sda2[/@/var/lib/named]
|-/var/log /dev/sda2[/@/var/log]
|-/var/crash /dev/sda2[/@/var/crash]
|-/home /dev/sda2[/@/home]
|-/usr/local /dev/sda2[/@/usr/local]
|-/var/lib/mailman /dev/sda2[/@/var/lib/mailman]
|-/opt /dev/sda2[/@/opt]
|-/srv /dev/sda2[/@/srv]
|-/boot/grub2/x86_64-efi /dev/sda2[/@/boot/grub2/x86_64-efi]
|-/tmp /dev/sda2[/@/tmp]
`-/boot/grub2/i386-pc /dev/sda2[/@/boot/grub2/i386-pc]
# mount -t btrfs -o subvolid=0 /dev/sda2 /tmp/btrfsroot && echo ok || echo failed
ok
# findmnt -at btrfs | cut -b-61
TARGET SOURCE
/ /dev/sda2[/@]
|-/var/tmp /dev/sda2[/@/var/tmp]
|-/var/spool /dev/sda2[/@/var/spool]
|-/.snapshots /dev/sda2[/@/.snapshots]
|-/var/lib/pgsql /dev/sda2[/@/var/lib/pgsql]
|-/var/opt /dev/sda2[/@/var/opt]
|-/var/lib/named /dev/sda2[/@/var/lib/named]
|-/var/log /dev/sda2[/@/var/log]
|-/var/crash /dev/sda2[/@/var/crash]
|-/home /dev/sda2[/@/home]
|-/usr/local /dev/sda2[/@/usr/local]
|-/var/lib/mailman /dev/sda2[/@/var/lib/mailman]
|-/opt /dev/sda2[/@/opt]
|-/srv /dev/sda2[/@/srv]
|-/boot/grub2/x86_64-efi /dev/sda2[/@/boot/grub2/x86_64-efi]
|-/tmp /dev/sda2[/@/tmp]
| `-/tmp/btrfsroot /dev/sda2
`-/boot/grub2/i386-pc /dev/sda2[/@/boot/grub2/i386-pc]
jsmeix commented at 2014-12-18 13:33:¶
I have a first tentative implementation of generic btrfs support
see
https://bugzilla.opensuse.org/show_bug.cgi?id=908854#c3
I have tested it only on SLES12 with btrfs where it seems to work for me.
Testing on other Linux distributions with btrfs is needed.
My tentative implementation should fail if there are "weaved btrfs
subvolume mounts", for details see
https://bugzilla.opensuse.org/show_bug.cgi?id=908854#c3
I will try to address "weaved btrfs subvolume mounts" in 2015.
For now:
Merry Christmas and a happy New Year!
jsmeix commented at 2014-12-18 13:41:¶
I have a general question regarding bash syntax:
At least down to GNU bash version 3.2.51 "man bash" reads:
case word in [ [(] pattern [ | pattern ] ... ) list ;; ] ... esac
which means the patterns can be in a pair of parenthesis like
case $var in (this) echo foo ;; (that) echo bar ;; (*) echo default ;; esac
I would like to use leading parenthesis for the cases to have pairs of matching parenthesis in the scripts.
gdha commented at 2014-12-18 15:42:¶
@jsmeix the findmnt command has been added to conf/GNU/Linux.conf
file
gdha commented at 2014-12-18 15:44:¶
The diff between
--- rear-1.16.1-git201412031625/usr/share/rear/layout/save/GNU/Linux/23_filesystem_layout.sh 2014-10-21 13:56:22.000000000 +0200
+++ rear-1.16.1-git201412031625.btrfs_generic/usr/share/rear/layout/save/GNU/Linux/23_filesystem_layout.sh 2014-12-18 13:27
are for tomorrow (I hope)
gdha commented at 2014-12-24 12:57:¶
Commit
https://github.com/rear/rear/commit/d663712a14e40d2ab7f900badd94298608300ab5
applied. Message note in bugzilla report
https://bugzilla.opensuse.org/show_bug.cgi?id=908854
Hoping @jsmeix will fork our mainstream for further testing btrfs
jsmeix commented at 2015-01-14 11:36:¶
Hello Gratien,
very many thanks for all your efforts to integrate my patch
into the mainstream of rear and for your testing!
Of course my further work will be based on the mainstream of rear.
Regaring Fedora:
I will try to change your current fix for Fedora into a generic solution.
I think I know what is different in Fedora's btrfs setup
that my code which is intended to be generic support for btrfs
currently does not work on Fedora:
I have installed Fedora-Live-Workstation-i686-21-5.
During its setup I selected Fedora's btrfs default partitioning scheme.
I got the following:
# fdisk -l ... Device Boot Start End Sectors Size Id Type /dev/sda1 * 2048 1026047 1024000 500M 83 Linux /dev/sda2 1026048 5220351 4194304 2G 82 Linux swap ... /dev/sda3 5220352 52428799 47208448 22.5G 83 Linux # btrfs subvolume list -a / ID 257 gen 62 top level 5 path/root ID 258 gen 44 top level 5 path /home # btrfs subvolume get-default / ID 5 (FS_TREE) # findmnt -t btrfs TARGET SOURCE FSTYPE OPTIONS / /dev/sda3[/root] btrfs rw,relatime,seclabel,space_cache `-/home /dev/sda3[/home] btrfs rw,relatime,seclabel,space_cache # mkdir /tmp/btrfsroot # mount -t btrfs -o subvolid=0 /dev/sda3 /tmp/btrfsroot # ls /tmp/btrfsroot home root # ls /tmp/btrfsroot/root bin boot dev etc home lib lost+found media mnt opt proc root run sbin srv sys tmp usr var # findmnt -t btrfs TARGET SOURCE FSTYPE OPTIONS / /dev/sda3[/root] btrfs rw,relatime,seclabel,space_cache |-/tmp/btrfsroot /dev/sda3 btrfs rw,relatime,seclabel,space_cache `-/home /dev/sda3[/home] btrfs rw,relatime,seclabel,space_cache # cat /etc/fstab | tr -s '[:blank:]' ... UUID=1b...df / btrfs subvol=root 0 0 UUID=bf...8d /boot ext4 defaults 1 2 UUID=1b...df /home btrfs subvol=home 0 0 UUID=1b...4a swap swap defaults 0 0
The crucial difference is that on Fedora what is in the running system mounted at the root of the filesystem tree (i.a. at the '/' mountpoint) is NOT the btrfs default subvolume but the btrfs subvolume "root".
This is shown in /etc/fstab.
Accordingly instead of testing for Fedora's btrfs way via a hardcoded subvolume name "root" by
if test "$subvolume_path" = "root" ; then
a more generic solution to test for Fedora's btrfs way should be to inspect /etc/fstab what is mounted at the '/' mountpoint and write that information to $LAYOUT_FILE.
jsmeix commented at 2015-01-14 15:34:¶
The required information is already provided by my current code:
On SLES 12 I have in disklayout.conf (excerpt):
# Format: btrfsdefaultsubvol device mountpoint btrfs_subvolume_ID [btrfs_subvolume_path] btrfsdefaultsubvol /dev/sda2 / 257 @ ... # Format: btrfsmountedsubvolume device subvolume_mountpoint mount_options btrfs_subvolume_path btrfsmountedsubvolume /dev/sda2 / rw,relatime,space_cache @
On SLES 12 the btrfs default subvolume is '@' and this one is mounted at the mountpoint '/' (as expected according to how a btrfs default subvolume is meant to be used).
On openSUSE 13.2 I have in disklayout.conf (excerpt):
# Format: btrfsdefaultsubvol device mountpoint btrfs_subvolume_ID [btrfs_subvolume_path] btrfsdefaultsubvol /dev/sda2 / 5 ... # Format: btrfsmountedsubvolume device subvolume_mountpoint mount_options btrfs_subvolume_path btrfsmountedsubvolume /dev/sda2 / rw,relatime,space_cache /
On openSUSE 13.2 the btrfs default subvolume is the btrfs root subvolume '/' (empty btrfs_subvolume_path for btrfsdefaultsubvol) and that one is mounted at the mountpoint '/' (as expected according to how a btrfs default subvolume is meant to be used).
On Fedora 21 I have in disklayout.conf (excerpt):
# Format: btrfsdefaultsubvol device mountpoint btrfs_subvolume_ID [btrfs_subvolume_path] btrfsdefaultsubvol /dev/sda3 / 5 ... # Format: btrfsmountedsubvolume device subvolume_mountpoint mount_options btrfs_subvolume_path btrfsmountedsubvolume /dev/sda3 / rw,relatime,seclabel,space_cache root
On Fedora 21 the btrfs default subvolume is the btrfs root subvolume '/' (empty btrfs_subvolume_path for btrfsdefaultsubvol) but that one is not mounted at the mountpoint '/' instead the btrfs subvolume 'root' is mounted at the mountpoint '/' (in contrast to how a btrfs default subvolume is meant to be used).
Accordingly I think I only need to enhance 13_include_mount_subvolumes_code.sh to deal with the (unexpected) case when not the btrfs default subvolume is mounted at the mountpoint '/' but another btrfs subvolume is mounted there.
I am not a btrfs expert but from my point of view it looks like a misconfiguration (a.k.a. bug) in Fedora 21 how they set up btrfs. I think Fedora should specify as btrfs default subvolume what is mounted at the '/' mountpoint.
Regardless if it is really a misconfiguration or not - I like to have rear working fail-safe because regardless what a Linux distribution does by default, an admin could manually create such an awkward btrfs setup and when then rear does not work it is of course a bug in rear ;-)
jsmeix commented at 2015-01-20 11:38:¶
I am testing rear git201501071534 version on Fedora 21
with special adaptions for generic btrfs support on Fedora
via rear-1.16.1-git201501071534.btrfs_generic_fedora.diff
in my openSUSE build service home project "home:jsmeix"
therein source package "rear1161git201501071534btrfsFedora"
that results RPMs rear1161btrfs-1.16.1.fedora-N.M.noarch.rpm
I had two minor issues with Fedora21 that I reported as
https://github.com/rear/rear/issues/531
and
https://github.com/rear/rear/issues/532
but basically recovery with generic btrfs support worked for me on
Fedora21.
Now I need to re-test if it still works on openSUSE and SLES12...
jsmeix commented at 2015-01-27 13:52:¶
I think this issue is now fixed via my last
commit 548965e045ac33c8aa02d5d284d590e7c0846ac9
"Implement basic support for btrfs in a generic way"
Note the "basic support".
Currently recovery works btrfs filesystem by btrfs filesystem.
Therefore it probably fails if there are
"interwoven btrfs subvolume mounts" which means
- a subvolume sv1 on a btrfs on /dev/sdXn
is mounted at a mountpoint directory
that belongs to a btrfs on /dev/sdYm - a subvolume sv2 on a btrfs on /dev/sdYm
is mounted at a mountpoint directory
that belongs to a btrfs on /dev/sdXn
In particular when the mountpoint directories are no plain directories
but also subvolumes sv3 and sv4 on any of the btrfs filesystems.
jsmeix commented at 2015-01-27 14:08:¶
FYI
Regarding "full btrfs support" (even for "interwoven mounts"),
see what I above "commented on 10 Dec 2014" in
https://github.com/rear/rear/issues/497#issuecomment-66448475
regarding a well separated component type "mount".
Currently recovery works $device by $device e.g.
first everything is done for /dev/sda
then everything is done for /dev/sdb.
But in case of "interwoven mounts" between /dev/sdXn and /dev/sdYm
this $device by $device recovery may fail.
Therefore for "full btrfs support" recovery should be done different:
- first "part" (creating partitions) on all devices,
- then "fs" (creating filesystems) on all partitions,
- then as needed "btrfssubvol" (creating btrfs subvolumes) on all btrfs filesystems,
- then if needed "btrfsdefaultsubvol" (setting btrfs default subvolume) on all btrfs filesystems,
- finally "mount" (creating mountpoints and mount stuff) for all filesystems and subvolumes.
gdha commented at 2015-02-06 13:29:¶
As the current btrfs implementation works on Fedora, SLES and OpenSuSe I declare this version ready for shipping with rear-1.17.
gdha commented at 2015-02-16 16:31:¶
added to the release notes so we can close this issue
[Export of Github issue for rear/rear.]