[systemd-devel] [HEADS-UP] Discoverable Partitions Spec

[Andrey Borzenkov]

В Fri, 7 Mar 2014 20:37:12 +0100
Lennart Poettering <lennart at poettering.net> пишет:

> On Fri, 07.03.14 20:47, Mantas Mikulėnas (grawity at gmail.com) wrote:
> 
> > 
> > On Fri, Mar 7, 2014 at 8:26 PM, Lennart Poettering
> > <lennart at poettering.net> wrote:
> > > Heya!
> > >
> > > Since yesterday systemd in git can now discover root, /home, /srv and
> > > swap partitions automatically based on GPT type GUIDs, thus making
> > > /etc/fstab unnecessary for simple setups.
> > >
> > > I have now put together something like a spec describing the logic
> > > behind that, and what it is good for:
> > >
> > > http://www.freedesktop.org/wiki/Specifications/DiscoverablePartitionsSpec/
> > >
> > > It would be good if in the long run OS installers could adopt this and
> > > use the right partition type GUIDs automatically, to make this discovery
> > > work. For now however, you need to manually change the GPT type GUIDs of
> > > your installation if you want to make use of this scheme.
> > 
> > That might not work very well if one tried to dual-boot two systemd
> > distros… 
> 
> Hmm? there are all kinds of provisions in the spec to make sure this
> works correctly. For example, we won't do this all for /usr and /var and
> /etc since we cannot allow incorrect mixing and matching between parallel
> installations. However, for /home and /srv that is much less of a
> problem, and sharing should be *good* in that case.
> 
> And for the root disk we declare explicitly that installers may only
> drop the root= param from the kernel cmdline if the OS is installed as
> first root partition on the disk. Otherwise it *must* specify it to make
> sure the right partition is found at boot.
> 
> Putting this altogether this should work fine for multi-boot cases. That
> said, the benefit of not requiring an /etc/fstab is primarily one for
> simpler "appliance" style disk images where only one OS is installed,
> not for the super generic full distro cases that want to support every
> possible storage setup. For example, I wouldn't expect anaconda to ever
> drop the root= param from the kernel cmdline of its installations. I
> mean, given that anaconda wants to support booting LVM on LUKS on RAID
> and iscsi on bonded vlans and whatever else, there's no auto-discovery
> like this possible anyway, and hence they can just keep the root= in
> there for everybody...
> 

So what is the benefit of creating specification and tools that nobody
will use? If distributions will have to support explicit filesystem
configuration anyway, what is the benefit for them to add *additional*
support for automatic configuration? Especially if this automatic
configuration is incomplete and has to be augmented with explicit
configuration anyway.

> > FAQ #1 talks about /usr and /etc, but /etc is almost always
> > in the root partition, isn't it?
> 
> Well, sure it is, and so is /var... But it certainly makes sense to have
> a seperate /etc in some cases. For example, in virtualized environments
> it might make sense to share a single fixed read-only /usr between a
> large number of containers that each have a private /etc and /var. 
> 
> I mean, this is the FAQ section, I am not saying whether splitting these
> things makes sense or no sense at all, I am just saying that
> auto-discovery makes no sense for these cases...
> 
> Lennart
>