On Thu, 27.02.14 17:47, Chris Murphy (li...@colorremedies.com) wrote: > > > On Feb 27, 2014, at 5:16 PM, Lennart Poettering <lenn...@poettering.net> > wrote: > > > On Thu, 27.02.14 17:06, Chris Murphy (li...@colorremedies.com) wrote: > > > >> > >> > >> On Feb 27, 2014, at 4:09 PM, Lennart Poettering <lenn...@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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel