linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Lennart Poettering <lennart@poettering.net>
To: Chris Murphy <lists@colorremedies.com>
Cc: Chris Mason <clm@fb.com>,
	kreijack@inwind.it, systemd-devel@lists.freedesktop.org,
	linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: [systemd-devel] [HEADS-UP] Discoverable Partitions Spec
Date: Mon, 10 Mar 2014 22:09:03 +0100	[thread overview]
Message-ID: <20140310210901.GA22199@tango.0pointer.de> (raw)
In-Reply-To: <1A252834-430D-482F-96C7-761A85D2DA74@colorremedies.com>

On Mon, 10.03.14 14:53, Chris Murphy (lists@colorremedies.com) wrote:

> Since it's not a given whether a parent or child subvolume is the one
> being updated, it's ambiguous which one to use/automount if there is
> inheritance of the proposed subvolumetypeGUID at snapshot
> time. Inheritance of the proposed GUID at snapshot time sounds
> untenable.
> 
> Failsafe for rootfs is to snapshot, mount it, apply updates to the
> snapshot in a chroot. That way a failed update means the snapshot can
> be immediately deleted. And the OS is overall more stable by not
> having running binaries modified or yanked out from under it. Here,
> using the current subvolume at reboot is the rollback; changing to the
> snapshot is the upgrade.
> 
> Whereas for home, rebooting to the snapshot is a rollback, which I
> certainly don't want by default.
> 
> I don't see the right way to handle this automatically or by default.

I am in no way bound to the idea of having subvolume type UUIDs for
this. There are other options. For example, there's already the concept
of having "default" subvolumes ("btrfs subvolume set-default"...), maybe
we can extend that a little bit, and allow different kinds of default
subvolumes, one "default /home subvolume", one "default /srv subvolume",
and so on, plus one "default root subvolume", and so on. The vocabulary
for the available "default" subvolumes could be a free-form string where
the empty string would be the existing default subvolume. Or so...

When people play games with subvolumes and snapshots we could then
simply ask them to update where these "default" subvolumes point... Of
course this simply exports to the admin the problem of combining
subvolumes properly.

Another option would be to introduce a high level concept of a
"subvolume set" or so, which binds subvolumes together, and of which
there could be a "default subvolume set". Within such a subvolume set
could then use type uuids or so to mount things properly. Or something
like that...

Lennart

-- 
Lennart Poettering, Red Hat

  reply	other threads:[~2014-03-10 21:09 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20140307182603.GA22874@tango.0pointer.de>
2014-03-10 18:34 ` [systemd-devel] [HEADS-UP] Discoverable Partitions Spec Goffredo Baroncelli
2014-03-10 18:53   ` Kay Sievers
2014-03-10 18:59     ` Goffredo Baroncelli
2014-03-10 19:43   ` Chris Murphy
2014-03-10 20:02   ` Lennart Poettering
2014-03-10 20:21     ` Chris Mason
2014-03-10 20:53       ` Chris Murphy
2014-03-10 21:09         ` Lennart Poettering [this message]
2014-03-10 22:44       ` Goffredo Baroncelli
2014-03-10 22:39     ` Goffredo Baroncelli
2014-03-10 23:45       ` Lennart Poettering
2014-03-10 23:59         ` Alex Elsayed
2014-03-11 14:30         ` [systemd-devel] " Calvin Walton
2014-03-12 17:24         ` Chris Mason
2014-03-12 19:12           ` Goffredo Baroncelli
2014-03-12 19:31             ` Chris Murphy
2014-03-12 19:55               ` Goffredo Baroncelli
2014-03-12 23:22               ` Brendan Hide
2014-03-12 22:18             ` Goffredo Baroncelli

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140310210901.GA22199@tango.0pointer.de \
    --to=lennart@poettering.net \
    --cc=clm@fb.com \
    --cc=kreijack@inwind.it \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=lists@colorremedies.com \
    --cc=systemd-devel@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).