#233 Issue closed: fedora19 btrfs subvolumes issues (diskrestore.sh)¶
Labels: bug, discuss / RFC
gdha opened issue at 2013-05-31 13:31:¶
On a fedora19 system we see the following:
# cat disklayout.conf
disk /dev/sda 8589934592 msdos
part /dev/sda 524288000 1048576 primary boot /dev/sda1
part /dev/sda 1912602624 525336576 primary none /dev/sda2
part /dev/sda 6151995392 2437939200 primary none /dev/sda3
#disk /dev/sdb 4294967296 msdos
fs /dev/sda3 / btrfs uuid=efcf1774-7cad-4fb4-8fcb-9d90a396d5b5 label='fedora' options=rw,relatime,seclabel,space_cache
fs /dev/sda3 /home btrfs uuid=efcf1774-7cad-4fb4-8fcb-9d90a396d5b5 label='fedora' options=rw,relatime,seclabel,space_cache
fs /dev/sda1 /boot ext4 uuid=70c882be-7672-4b4f-8b19-51b66b7f2561 label= blocksize=1024 reserved_blocks=5% max_mounts=-1 check_interval=0d bytes_per_inode=4095 options=rw,relatime,seclabel,data=ordered
swap /dev/sda2 uuid=d5bac901-323f-40a8-84ca-e2bfb79efa7c label=
# df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda3 6007808 2925784 2781640 52% /
devtmpfs 391928 0 391928 0% /dev
tmpfs 402296 72 402224 1% /dev/shm
tmpfs 402296 840 401456 1% /run
tmpfs 402296 0 402296 0% /sys/fs/cgroup
tmpfs 402296 20 402276 1% /tmp
/dev/sda3 6007808 2925784 2781640 52% /home
/dev/sda1 487652 74593 387459 17% /boot
As you can see it is odd to see /dev/sda3 twice listed in
disklayout.conf (in particular / and /home).
Of course, in recovery mode, that gives trouble (trying do a mkfs on
/dev/sda3 twice). This is not really the fault of rear, but still rear
gets the blame (I guess).
We can fix this manually in the diskrestore.sh script, and the restore
is successful afterwards.
Reboot the system and then it seems that not all uuids were correctly migrated (perhaps in the initrd??) and we're dropped into a rescue prompt of dracut-initqueue.
gdha commented at 2013-05-31 13:34:¶
some extra info:
# cat /etc/fstab
UUID=efcf1774-7cad-4fb4-8fcb-9d90a396d5b5 / btrfs subvol=root 1 1
UUID=70c882be-7672-4b4f-8b19-51b66b7f2561 /boot ext4 defaults 1 2
UUID=efcf1774-7cad-4fb4-8fcb-9d90a396d5b5 /home btrfs subvol=home 1 2
UUID=d5bac901-323f-40a8-84ca-e2bfb79efa7c swap swap defaults 0 0
# ll /dev/disk/by-uuid/
total 0
lrwxrwxrwx. 1 root root 10 May 31 09:58 70c882be-7672-4b4f-8b19-51b66b7f2561 -> ../../sda1
lrwxrwxrwx. 1 root root 10 May 31 09:58 d5bac901-323f-40a8-84ca-e2bfb79efa7c -> ../../sda2
lrwxrwxrwx. 1 root root 10 May 31 09:58 efcf1774-7cad-4fb4-8fcb-9d90a396d5b5 -> ../../sda3
ok, / and /home are sub-volumes and share the same uuid - that must be
the reason why rear got confused.
What is exactly shown as labels?
# btrfs filesystem show --all-devices
Label: 'fedora' uuid: efcf1774-7cad-4fb4-8fcb-9d90a396d5b5
Total devices 1 FS bytes used 2.53GB
devid 1 size 5.73GB used 3.50GB path /dev/sda3
Btrfs v0.20-rc1
gdha commented at 2013-06-04 12:56:¶
In the disklayout.conf file we should add the entries:
fs /dev/sda3 / btrfs uuid=efcf1774-7cad-4fb4-8fcb-9d90a396d5b5 label='fedora' options=rw,relatime,seclabel,space_cache
fs /dev/sda3 /home btrfs uuid=efcf1774-7cad-4fb4-8fcb-9d90a396d5b5 label='fedora' options=rw,relatime,seclabel,space_cache
into
fs /dev/sda3 / btrfs uuid=efcf1774-7cad-4fb4-8fcb-9d90a396d5b5 label='fedora' options=rw,relatime,seclabel,space_cache,subvol=home
fs /dev/sda3 /home btrfs uuid=efcf1774-7cad-4fb4-8fcb-9d90a396d5b5 label='fedora' options=rw,relatime,seclabel,space_cache,subvol=root
The sub-volumes can be seen with:
# btrfs subvolume list -a /
ID 256 gen 19 top level 5 path <FS_TREE>/home
ID 258 gen 350 top level 5 path <FS_TREE>/root
And, even a bit more details:
# btrfs subvolume show /
/
Name: root
uuid: aa27988c-5f42-d14b-9247-30b0275317a6
Parent uuid: -
Creation time: 2013-05-30 08:24:52
Object ID: 258
Generation (Gen): 381
Gen at creation: 8
Parent: 5
Top Level: 5
Flags: -
Snapshot(s):
# btrfs subvolume show /home
/home
Name: home
uuid: f05e8187-ee74-ad4c-a302-c6c7e31f749b
Parent uuid: -
Creation time: 2013-05-30 08:24:52
Object ID: 256
Generation (Gen): 19
Gen at creation: 5
Parent: 5
Top Level: 5
Flags: -
Snapshot(s):
gdha commented at 2013-06-06 14:08:¶
Hum, recovery was after some tweeking successful. However, at the next
reboot:
we get an error of the initqueue - the UUID seems correct, but need some
more investigation...
gdha commented at 2013-06-25 14:20:¶
OpenSuSe 12.3 the command btrfs subvolume list / looks like:
ID 256 top level 5 path tmp
ID 258 top level 5 path opt
ID 259 top level 5 path srv
ID 260 top level 5 path var/crash
ID 261 top level 5 path var/spool
ID 262 top level 5 path var/log
ID 263 top level 5 path var/tmp
ID 268 top level 5 path .snapshots
ID 269 top level 5 path .snapshots/1/snapshot
ID 270 top level 5 path .snapshots/2/snapshot
ID 271 top level 5 path .snapshots/3/snapshot
ID 272 top level 5 path .snapshots/4/snapshot
ID 273 top level 5 path .snapshots/5/snapshot
ID 274 top level 5 path .snapshots/6/snapshot
ID 275 top level 5 path .snapshots/7/snapshot
ID 276 top level 5 path .snapshots/8/snapshot
ID 277 top level 5 path .snapshots/9/snapshot
ID 278 top level 5 path .snapshots/10/snapshot
ID 279 top level 5 path .snapshots/11/snapshot
ID 280 top level 5 path .snapshots/12/snapshot
ID 281 top level 5 path .snapshots/13/snapshot
ID 282 top level 5 path .snapshots/14/snapshot
ID 283 top level 5 path .snapshots/15/snapshot
ID 284 top level 5 path .snapshots/16/snapshot
ID 286 top level 5 path .snapshots/17/snapshot
The code in script
layout/prepare/GNU/Linux/13_include_filesystem_code.sh will not work
on OpenSuse:
echo "btrfs_id=\$(btrfs subvolume list /mnt/local$mp | tail -1 | awk '{print \$2}')" >> $LAYOUT_CODE
pavoldomin commented at 2014-08-18 19:40:¶
Hello,
I am just evaluating sles11.3 btrfs support; indeed ReaR would not be capable to recover the YaST default subvolume layout. The point is, ReaR takes fs layout from the 'mount' output, but btrfs subvolumes may not be "mounted", yet still visible in the / tree, just as the example in the comment above shows. Therefore, I believe btrfs deserves dedicated layout code, as its not just filesystem but also a volume manager. What about new disklayout.conf entries like:
btrfs_subvol <btrfs subvolume list output>
....
btrfs_snapshot <btrfs subvolume list -s output>
....
The fs recovery code would than construct corresponding
btrfs subvolume {create|snapshot|set-default} commands after fs
creation and before actual mount. What do you think?
I may find a time to make some basic implementation for this, if you
find this suggestion reasonable.
gdha commented at 2014-08-19 06:56:¶
@pavoldomin I like the idea as currently btrfs is a nightmare the way it
is implemented across the different Linux distro's. We would be happy to
accept a pull request around new layout code for btrfs.
@rear/contributors Any other suggestions or comments?
pavoldomin commented at 2014-08-19 07:07:¶
...With the one additional correction. Obviously,
btrfs_snapshot <btrfs subvolume list -s output> make little sense, as
there is no tool (none that i am aware of) to backup/restore btrfs
snapshots.
gdha commented at 2014-11-03 15:02:¶
@rear/contributors The
usr/share/rear/layout/prepare/GNU/Linux/13_include_filesystem_code.sh
script contains one big functions create_fs which is called from
usr/share/rear/lib/layout-functions.sh section
create_$type "$device" to recreate the file system and mount it under
/mnt/local/
However, the btrfs file system is becoming so complex to mount
something with its sub-volumes etc., and furthermore the way to do it
differs between the Linux distro's I think it would become wiser to make
a separate script under the Linux distro directories, e.g. SUSE_LINUX
or Fedora to mount it. Perhaps we could make a script
14_mount_filesystem_code.sh with a function mount_fs.
E.g. layout/prepare/GNU/Linux/13_mount_filesystem_code.sh and
layout/prepare/SUSE_LINUX/i386/14_mount_filesystem_code.sh (use 14 for
as distro related code which is higher than 13 - so we are sure it
overrules the generic mount_fs function).
All feedback is welcome...
gdha commented at 2015-01-25 17:09:¶
Issue #497 also includes fedora btrfs support - we can close this one
[Export of Github issue for rear/rear.]