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

[Chris Murphy]

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.

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.

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.

I'd also suggest the OSTree project as topic.

And if there's room for file system and security issues, I'm still rather curious about the possibility of separate trees (or snapshots) exposing stale binaries with known exploits.

I started this thread ostensibly about btrfs snapshot questions, but it may also be relevant for OSTree snapshots.
https://lists.fedoraproject.org/pipermail/security/2014-February/001748.html


Chris Murphy