Re: the need for a discoverable sub-volumes specification

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Nov 9, 2021 at 3:57 PM Lennart Poettering
<lennart@xxxxxxxxxxxxxx> wrote:

> Now, at least in theory we could declare the same for this new
> directory auto-discovery scheme. But I am not entirely sure this will
> work out trivially IRL because I have the suspicion one cannot rename
> subvolumes which are the source of a bind mount (i.e. once you boot
> into one root subtree, then it might be impossible to rename that
> top-level inode without rebooting first).

You can rename them. Behind the scenes, subvolumes are tracked by
subvolid, which doesn't change. So literally nothing cares if you
rename it, including a live root subvolume. I do something like this
all day long to do a rollback:

mv root rootbad3
btrfs sub snap root.20211210clean root
reboot

That's because 'rootflags=subvol=root' by default on Fedora. Whereas
on (open)SUSE you'd issue a snapper command to rollback which takes
one or more snapshots, then changes the default subvolume.

Immediately after the 'mv' command, 'mount' shows the / mount point as
being subvol=/rootbad3

A point of confusion in the Fedora fstab is the '/' entry that uses
subvol=, e.g.

UUID=$UUID /               btrfs   subvol=root 0 0

This is just an artifact of the installer's fstab generator, it's
actually pointless because the / entry in an fstab is a remount at
switch root time. And we can't change subvolumes with 'mount -o
remount' anyway. So the option is rendered meaningless. Likewise,
there's confusion over the per mount point option "compress=zstd:1"
which is a per file system mount option, not a per subvolume one. But
again, artifact of the installer. The only one that matters is the one
for '/' because "mount -o remount,compress=zstd:1" is valid, where
subsequent mount points are not remount, but additional bind mounts.
It is absolutely reasonable that users become confused, because it is
confusing.

> (Yeah, the subvol= mount option for btrfs would work too, but as
> mentioned I'd keep this reasonably independent of btrfs where its
> easy, plain dirs otherwise are fine too after all. Which reminds me,
> recent util-linux implements the X-mount.subdir= mount option, which
> means one could also use 'rootflags=X-mount.subdir=@auto/fedora_36.2'
> as non-btrfs-specific way to express the btrfs-specific
> 'rootflags=subvol=@auto/fedora_36.2')

Neat.

-- 
Chris Murphy



[Index of Archives]     [LARTC]     [Bugtraq]     [Yosemite Forum]     [Photo]

  Powered by Linux