On Wed, Apr 22, 2020 at 10:42 AM Stefanie Leisestreichler <stefanie.leisestreichler@xxxxxxxxxxxxxx> wrote: > > Hi. > I wonder how to partition my Disks when I want to use btrfs in a RAID 1 > configuration. > I have /dev/sda1 and /dev/sdb1 for UEFI/ESP (no btrfs) and think about > using just 1 more GPT-Partition on each disk /dev/sd[a|b]2 for btrfs. I > am planing to create a btrfs-RAID 1 on those two partitions. > > > This is what the wiki says about partitioning: > > Do it the old fashioned way, and create a number of partitions according to your needs? Or create one big btrfs partition and use subvolumes where you would normally create different partitions? > > > > What are the considerations for doing it either way? > > My use case is a KVM Host running Arch Linux with 3-4 Virtual Machines. > I want to have the ability to take snapshots when my system will be > updated to restore a running system if something is broken by the > update. I read about the mount option which disables CoW for database > and VM images. > > About the subvolume layout and partitioning I am unsure even I read the > wiki. What do people familar with btrfs recommend for such setup? The gotcha with Btrfs is that it's very flexible, so there are no strict rules, only consequences to any decision :D One example is to install openSUSE using defaults, and see how they do it with roughly a dozen subvolumes to carve out what does and does not get snapshot and rolled back. Another example is on Fedora where only boot, root, and home subvolumes are created and mounted at /boot, /, /home accordingly. It's fairly easy to do snapshots and rollbacks manually, because you only need to rollback the root subvolume (if there were no kernel updates). e.g. ## mount the top level file system and cd to it # mv root rootold # btrfs sub snap root.20200420 root # reboot It's that simple. The system doesn't care that you're renaming a currently booted 'root' subvolume to 'rootold' and then creating a new 'root' from a prior snapshotted 'root'. And now grub and fstab don't need modification because you've merely substituted an older subvolume of the same name that they're looking for anyway. What's the gotcha? Well, my /var has been rolled back, and also the systemd journal. OK so I could make /var/lib/libvirt and /var/log subvolumes so they don't get snapshot and rolled back. What I tend to do is put those in the top level of the file system, and have fstab entries to mount them to the proper location during startup, that way I don't have to worry about manually fixing things on a rollback. The more carving you do, the more help you're likely to want when making snapshots and rollbacks. Something like snapper, found on opensuse by default, or something like timeshift on Mint/Ubuntu. For throw away test machines, I tend to go with the very simple approach, few subvolumes, and just accept that any rollback means a kind of data loss for logs and other things in /var. These tend to be VMs, so I don't really care about the journal being rolled back, and I don't have nested VMs. To some degree, such a workflow is better served by containers, but it just depends on your use case and what tools you're familiar with. -- Chris Murphy
