[systemd-devel] [PATCH] rules: add by-parttypeuuid rule for GPT labeled partitions

Sage Weil sage at inktank.com
Fri May 9 15:00:55 PDT 2014


Hi Kay,

On Fri, 9 May 2014, Kay Sievers wrote:
> On Fri, May 9, 2014 at 11:31 PM, Sage Weil <sage at inktank.com> wrote:
> > The Ceph OSD initialization relies on identifying GPT partitions by type
> > in order to mount data volumes and start daemons.  Currently we ship this
> > rule separately, but it is awkward to duplicate the conditional logic that
> > precedes this block and it would be much simpler if it were simply included
> > in the upstream rules.
> 
> Types are by definition not unique. The symlinks in /dev/disk/by-*/
> are *expected* to be unique.
> 
> We handle duplicated labels, but they are specified by humans,
> multiple partitions with the same GPT types are just normal expected
> behavior; and they would have no order or priority, they just
> overwrite each other depending on probing order.

This is why the label has both the type (fixed, to identify this as a ceph 
partition) and the label (random):

 /dev/disk/by-parttypeuuid/$env{ID_PART_ENTRY_TYPE}.$env{ID_PART_ENTRY_UUID}

> We should not add such things, the logic to find these volumes at
> bootup are better handled by a specific program like systemd's
> systemd-gpt-auto-generator, without putting unreliable and
> unpredictable content into /dev.

I think this is what we're trying to accomplish with the ceph-disk tool, 
which relies on these (reliable and predictable) symlinks.  The labels 
alone (by-partuuid) aren't sufficient since we want to be able to scan for 
partitions of a given type without re-running blkid on every volume.

Right now sysvinit, upstart, and udev may trigger ceph-disk to activate 
volumes. Hopefully we'll have native systemd support sometime soon.  But 
first I want to make sure the approach has been validated, and hopefully 
avoid shipping custom rules...

Thanks!
sage


More information about the systemd-devel mailing list