On 10/17/2016 08:54 PM, Bruno Friedmann wrote:
On lundi, 17 octobre 2016 21.49:19 h CEST Michael Hamilton wrote:
I was looking to make an exact copy of a tumbleweed root btrfs filesystem on removable media. One aspect that makes this more fiddly is the number of subvolumes that are part of the root filesystem, including /opt and many sub-directories of /var.
Is there any technical document describing the reasons behind having so many subvolumes? Someone else was asking the same question at stackexchange (with no real answers) :
http://unix.stackexchange.com/questions/285011/why-does-my-tumbleweed-opensu se-fstab-contain-so-many-btrfs-subvol-entries
Is there a recommended way to get a faithful offline bootable backup of a btrfs rootfs?
Finally, I'm not determined to use btrfs. I'm moving up from 13.1. I'm evaluating Leap and Tumbleweed. It's a simple desktop, no RAID, one user. Would ext4 be a better choice?
Regards, Michael
From my experience, I'm a btrfs breaker guy (The why has still to be determined :-) ). So for my own laptop, I using the traditionnal luks encrypted vg/lvm + lvm with ext4, this as been rock solid for my own usage, even when I trash the power outlet. But there's a downside, I'm not using snapper/ext4) and then loose the ability to use a rollback snapshot. I have to be careful when doing update with TW.
;-)
The main reason of having that much subvolume from some clues I got from internet is for example, that there's no way to have checksum (interesting for database for example) without cow (copy on write, which is not interesting for database). The nocow flag disable also checksumming. (beware those informations can be outdated since I've test them 6-8 months ago) Also subvol are related also to quota.
The other reason is to avoid the data being captured in a disk snapshot that can be used too roll back later, for example generally if you need to roll back to a earlier snapshot to recover your system rolling back the contents of /tmp /var/cache etc is not useful. You also wouldn't want to roll back /var/logs as you'd loose data. By having these in a separate snapshot this wont happen. Also someone has now answered the stack overflow question covering both these reasons. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adeliade Australia, UTC+9:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B