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
Requested by: Dainius Masiliunas (greatemerald)
Partner organization: openSUSE.org
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.
- installer creates unexpected partition layout when specifying btrfs
- Upstream suggested Btrfs filesystem structure (url:
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):
: 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.
#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
#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):
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.