Hi Kay,
On Fri, 9 May 2014, Kay Sievers wrote:
> On Fri, May 9, 2014 at 11:31 PM, Sage Weil <sage@xxxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
