Re: btrfs subvolume naming scheme
On 23 April 2016 at 07:38, New Thread old subject joining team
<stappers@stappers.nl> wrote:
> On Sat, Apr 23, 2016 at 01:28:43PM +0200, Philipp Kern wrote:
>> On Fri, Apr 22, 2016 at 08:30:35PM -0400, Nicholas D Steeves wrote:
>>
>> > I'd also like to discuss whether the default subvolume naming scheme
>> > should follow Ubuntu, Fedora, OpenSUSE, or something else.
>>
>> What scheme are they using?
>
> Or a proposal for default subvolume naming scheme?
>
Ubuntu avoids using the default subvolume (subvol ID 5). For the
rootfs their installer creates a subvol called @, for /home it creates
@home, etc. In fstab the device is specified and subvol=@ is added to
the mount option to specify which subvolume gets mounted. When the
volume is mounted without a subvol option, it mounts the whole tree.
The tree would be /btrfs/@ and /btrfs/@home if mounted from a rescue
disk.
I think the symbol is visually striking, but it can be cumbersome
because @+<tab> sometimes autocompletes as ipv6 addresses for root.
I'm also not sure if @ ever needs to be escaped \@.
Oh! I just booted OpenSUSE Leap (their LTS), and it looks like
they've now adopted the Ubuntu convention of using @. OpenSUSE has
also, to my knowledge, always avoided using the default subvolume.
Furthermore, OpenSUSE creates subvolumes for just about everything
@opt, @srv, @tmp, @usr/local, @var/crash, etc.
Fedora 23 Workstation: When btrfs-style partitioning is selected,
their installer creates two subvolumes, home, and root. When the
volume is mounted to /btrfs without a subvol= option, the tree would
be /btrfs/home and /btrfs/root. Like Ubuntu and OpenSUSE default
subvolume is also not used. From what I gather this is a necessary
configuration to support btrfs send and receive. Eg: Bug #764056 is a
result of our current policy.
Unlike LVM or disk partitions, all free space is shared between
subvolumes. In the future it will be possible to use qgroups (quota
groups) to prevent /var or /home from using up all available free
space in rootfs, but at this time I don't think we should support it
in the installer, because of the volume of associated bugs and code
churn on the linux-btrfs mailing list. Also, in the future it will be
possible to mount subvolumes with different options, but at this time
the first subvolume mounted sets the mount options for all members of
the volume--I'm not sure how to address this the D-I.
In consultation with
https://btrfs.wiki.kernel.org/index.php/SysadminGuide#When_To_Make_Subvolumes
, a subvolume for rootfs and for /home seems sane, and sysadmins can
be instructed to consider making a subvolume for /var/www in
documentation.
This brings us to a concern I have for documentation. How should
/var/www appear when it's mounted using a rescue disk? Should it be
/btrfs/var_www? If it was /btrfs/var/www, then the two possibilities
are:
a) /btrfs/var is its own subvolume
and /btrfs/var/www is a child subvolume of /btrfs/var
note: strictly speaking, all subvolumes what seems to be the root
volume are actually children of the default subvolume...the semantics
get tricky very quickly!
or
b) /btrfs/var is a normal directory
and in the case of /btrfs/var/www, www is actually a child of /btrfs.
Finally, because subvolumes are partitions in POSIX namespace, it's
safe to mount a subvolume to two locations, and also to have a
/btrfs-admin directory where the whole volume is mounted, at the same
time as individual subvolumes are mounted. eg: you have your rootfs
mounted at /, and also at /btrfs-admin/rootfs or /btrfs-admin/@.
The primary reason to do this is because most of the btrfs tools
operate on mountpoints rather than on devices. It also allows
centralisation of snapshots. eg: /btrfs-admin/snapshots is a normal
directory that holds snapshots of /btrfs-admin/rootfs,
/btrfs-admin/home, etc.
Résumé: Do we follow Ubuntu and OpenSUSE with the @ convention and
work through the issues in bash-completion, or we follow Fedora's
plain text/alphanumeric convention, or do we do our own thing?
Secondly, Do we want to limit the difficulty of supporting complicated
configurations by establishing simple conventions and recommendation
early on? eg: all subvolumes created in the installation are peers,
and a subvolume that will be mounted at /var/www is named var_www. A
default delimiter convention would also need to be chosen.
I look forward to your replies,
Cheers!
Nicholas
Reply to: