[systemd-devel] Topics for the Linux Storage, Filesystem & MM Summit

[Lennart Poettering]

On Thu, 27.02.14 17:47, Chris Murphy (lists at colorremedies.com) wrote:

> 
> 
> On Feb 27, 2014, at 5:16 PM, Lennart Poettering <lennart at poettering.net> wrote:
> 
> > On Thu, 27.02.14 17:06, Chris Murphy (lists at colorremedies.com) wrote:
> > 
> >> 
> >> 
> >> On Feb 27, 2014, at 4:09 PM, Lennart Poettering <lennart at poettering.net> wrote:
> >> 
> >>> - uuids for btrfs subvols
> >> 
> >> btrfs subvol show <pathtosubvolume>
> >> 
> >> It will show the subvol uuid, and if it's a snapshot it will also show
> >> the parent uuid. If you mean partitiontypeGUID so we have some idea
> >> what the purpose of these subvolumes is, like the unique
> >> partitiontypeGUID for home? Could be useful. Certainly there could be
> >> some additional metadata for tracking the relationship between many
> >> subvolumes as well as purpose.
> > 
> > Oh, sorry, yeah, i meant subvolume *type* UUIDs, indeed. i.e. like
> > the partition type UUIDs that GPT exposes for every partition. 
> > 
> > And yupp, this is about discovering automatically where to mount what
> > when just looking at a btrfs volume. 
> > 
> >> Possibly a snapshot family, that describes multiple subvolumes; and
> >> then use that information for a systemd mount job, it would make fstab
> >> mostly obsolete.
> > 
> > Instead of supporting too much flexibility I'd try to focus on
> > collecting the subvolumes by a simple rule, for example: just take the
> > first subvolumes with the right type uuids, or just take the oldest or
> > the newest ones, or so…
> 
> I think this gets really dangerous really fast if we're talking about
> a bunch of snapshots which would presumably inherit the parent's
> subvolumetypeGUID. Already on openSUSE by default with Btrfs systems
> snapper takes before and after snapshots before every system update so
> it quickly gets to hundreds of snapshots.
> 
> On Btrfs there's no such thing as simple unless snapshots are
> proscribed. Otherwise it needs to tie specific snapshots together so
> they don't end up being mounted sync, like a the wrong /boot with a
> new kernel and old rootfs with the wrong version /lib/modules. Also
> it's not assumable that the newest or oldest of anything is the right
> thing to mount, because the user might have created a branch with
> snapshot.

Well, this is precisely the set of reasons why we don't do GPT
auto-discovery for /var either: we do not want to get into the risk of
matching up versions that do not belong together. This isn't any
different for btrfs either: we should simply not do this for /var. If
people want to split off /var into their own subvol, then they are
welcome, but they need to add an explicitly reference to it in
/etc/fstab, as they always did.

> Further :-) arguably we shouldn't have a /home subvolume but rather
> user subvolumes to snapshot because users could independently snapshot
> and rollback their own home, that shouldn't affect other user's home.

Precisely, that's why we do automatic discovery on GPT for /home, but
not for /var.

I think we should auto-discover the root subvol (from the initrd), and
/home, and maybe /srv, but little else.

> And even more esoteric but realistic examples exist.
> 
> Possible the OSTree project is a better way to manage these
> semantics. It hides and manages all possible trees, it works on any
> file system, and can use LVM thinp or Btrfs snapshots (or reflinks) as
> an optimization where appropriate.
> 
> But overall this is still a good discussion to explore at LSF. And for
> that matter, LVM LV's maybe need an LVtypeGUID to be equivalent to
> partitiontypeGUID and subvolumetypeGUID.

Well, from the systemd side we will not support LVM directly. They are
welcome to add this, but I don't want to see a hook-up for this in
systemd.

Lennart

-- 
Lennart Poettering, Red Hat