Feature changed by: Matthias Eckermann (mge1512) Feature #314606, revision 13 Title: Improved Btrfs subvolume management in YaST Partitioner - openSUSE Distribution: Unconfirmed + openSUSE Distribution: Evaluation by project manager Priority Requester: Desirable Requested by: Dainius Masiliunas (greatemerald) Partner organization: openSUSE.org Description: The current implementation of Btrfs subvolume management is a bit too simplistic. It allows adding and removing subvolumes, but that is all. Expanding this to view subvolumes as actual subvolumes would be beneficial. Perhaps something akin to LVM configuration, as Btrfs subvolumes can handle much of what LVM does. At the same time, this could allow easier interfacing with Snapper. Relations: - installer creates unexpected partition layout when specifying btrfs (novell/bugzilla/id: https://bugzilla.novell.com/show_bug.cgi?id=841944) https://bugzilla.novell.com/show_bug.cgi?id=https://bugzilla.novell.com/show... - Upstream suggested Btrfs filesystem structure (url: https://btrfs.wiki.kernel.org/index.php/SysadminGuide#Managing_snapshots) Use Case: When using Btrfs as the main file system, it is useful to have a single Btrfs partition for both / and /home, as it allows for more efficient disk space use. When reinstalling and upgrading, it is now a problem, as there is no way to remove certain subvolumes and leave others, and keeping /home between installations is often useful. Another case is when a multi-device Btrfs volume is desirable. The YaST partitioner only allows creating "regular" Btrfs partitions right now. A feature like that would also be useful for tighter Snapper integration. It would be a convenient place to set which volumes should be monitored by it, and which are not. In addition, it would help resolve a few bugs, such as the failure to automatically create subvolumes for excluding directories from Snapper monitoring when choosing to format the Btrfs partition. Business case (Partner benefit): openSUSE.org: UI enables user to more easily manage storage resources. Future features will be per subvolume raid levels, compression, and quotas. The analogy to LVM is apt although it's more like LVM thin provisioning, with some minor terminology differences. Discussion: #1: Chris Murphy (kopathangawa) (2013-09-24 18:48:20) I filed bug 841944 (https://bugzilla.novell.com/show_bug.cgi?id=841944) which partly applies to this. By default home probably should be a subvolume rather than a separate partition/btrfs volume, especially because snapshotting rootfs with only 40GB is quickly going to eat up space. Further rootfs should be on its own subvolume, rather than on default subvolume id 5, so that it's easier to snapshot or delete when doing a reinstall to a new subvolume and thus helps enable retaining the home subvolume when reinstalling. The installer should allow a new install to an existing btrfs volume, via creation of a new subvolume for rootfs rather than a reformat. Presently, the part that I think is still a bug, is that 13.1 beta 1 creates a home subvolume on roots and also creates a separate partition for home formatted as btrfs. While I'm arguing for one btrfs volume and home as subvolume, at least pick one method or the other rather than both. #2: Dainius Masiliunas (greatemerald) (2014-07-30 22:58:54) I just ran into another usecase (actually related to bug #841944). The official btrfs wiki suggests using a layout where the root of the filesystem is empty save for subvolumes (for / and /home): https://btrfs.wiki.kernel.org/index.php/SysadminGuide#Managing_snapshots Then using subvolume mounts the subvolumes would be mounted as / and /home. This layout has a lot of advantages, because as mentioned in bug #841944 you want to be able to reinstall without erasing /home, and with btrfs that's done by erasing the / subvolume and leaving /home subvolume intact. That's overly problematic if /home is a subvolume inside /, because you'd have to figure out which files don't belong to /home and erase all the rest manually (instead of issuing a single btrfs subvolume delete command). At the moment, you can't create such a layout in YaST, nor in fact install into such a layout if you set it up manually beforehand (without a lot of problems and hacks, at least), because YaST only understands partitions and not subvolumes. #3: Matthias Eckermann (mge1512) (2014-07-31 09:01:25) (reply to #2) Interestingly, YaST _can_ create this kind of setup, and it does so on SUSE Linux Enterprise 11 (and upcoming SUSE Linux Enterprise 12). As far as I know, there is one switch in the YaST control.xml file on the ISO which controls this behaviour, but for openSUSE 13.1 it was decided by the release team to not enable it. -- openSUSE Feature: https://features.opensuse.org/314606