* Re: Behavior with duplicate UUID's
2010-08-09 1:19 Behavior with duplicate UUID's Scott Talbert
@ 2010-08-09 8:02 ` Kay Sievers
2010-08-11 3:05 ` Scott Talbert
2010-08-11 8:17 ` Kay Sievers
2 siblings, 0 replies; 4+ messages in thread
From: Kay Sievers @ 2010-08-09 8:02 UTC (permalink / raw)
To: linux-hotplug
On Mon, Aug 9, 2010 at 03:19, Scott Talbert <talbert@techie.net> wrote:
> I am looking at udev's behavior when duplicate UUID's are present (ie,
> partition a and partition b both have the same UUID) in a system. Yes, this
> is a rather rare case, but it can happen if, for instance, one partition is
> cloned to another.
>
> Right now, it appears that the behavior for creating the /dev/disk/by-uuid
> links is "last one in wins." For example, if I have /dev/sda1 with UUID X
> in a system, and then add another drive with a /dev/sdb1 with UUID X,
> /dev/sdb1 ends up with its link in /dev/disk/by-uuid. It would seem to me
> that "first one in wins" might be a better approach. That is, when
> /dev/sdb1 comes along later, /dev/sda1's link would persist in
> /dev/disk/by-uuid.
The behavior is undefined, and can only be controlled with
link_priority= option.
We can't, and don't want to pretend to make any control over 'the
first one'. In a hotplug world, there is almost never a correct first
one, because everything runs in parallel.
Kay
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Behavior with duplicate UUID's
2010-08-09 1:19 Behavior with duplicate UUID's Scott Talbert
2010-08-09 8:02 ` Kay Sievers
@ 2010-08-11 3:05 ` Scott Talbert
2010-08-11 8:17 ` Kay Sievers
2 siblings, 0 replies; 4+ messages in thread
From: Scott Talbert @ 2010-08-11 3:05 UTC (permalink / raw)
To: linux-hotplug
On Mon, 9 Aug 2010, Kay Sievers wrote:
> The behavior is undefined, and can only be controlled with
> link_priority= option.
>
> We can't, and don't want to pretend to make any control over 'the
> first one'. In a hotplug world, there is almost never a correct first
> one, because everything runs in parallel.
I agree with you that if two devices are hotplugged at around the same
time, the result would be expectedly unpredictable. However, if you have
your root partition (with a symlink established at bootup), and then hours
later, you hotplug another device, it would seem to me that the symlink of
the older device would be preferable to keep. Right now, the symlink for
the original device is removed and a symlink for the new one is added.
I propose a slightly different change. This changes the symlink priority
processing when the priorities are the same. The oldest symlink is
instead preferred, rather than the newest one.
--- udev-node.c.orig 2010-05-20 11:06:52.000000000 -0400
+++ udev-node.c 2010-08-10 22:52:53.000000000 -0400
@@ -261,9 +261,10 @@
devnode = udev_device_get_devnode(dev_db);
if (devnode != NULL) {
- dbg(udev, "compare priority of '%s'(%i) > '%s'(%i)\n", target, priority,
- udev_device_get_devnode(dev_db), udev_device_get_devlink_priority(dev_db));
- if (target = NULL || udev_device_get_devlink_priority(dev_db) > priority) {
+ dbg(udev, "compare priority of '%s'(%i) >= '%s'(%i)\n",
+ udev_device_get_devnode(dev_db), udev_device_get_devlink_priority(dev_db),
+ target, priority);
+ if (target = NULL || udev_device_get_devlink_priority(dev_db) >= priority) {
info(udev, "'%s' claims priority %i for '%s'\n",
udev_device_get_syspath(dev_db), udev_device_get_devlink_priority(dev_db), stackdir);
priority = udev_device_get_devlink_priority(dev_db);
---
Thanks,
Scott
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: Behavior with duplicate UUID's
2010-08-09 1:19 Behavior with duplicate UUID's Scott Talbert
2010-08-09 8:02 ` Kay Sievers
2010-08-11 3:05 ` Scott Talbert
@ 2010-08-11 8:17 ` Kay Sievers
2 siblings, 0 replies; 4+ messages in thread
From: Kay Sievers @ 2010-08-11 8:17 UTC (permalink / raw)
To: linux-hotplug
On Wed, Aug 11, 2010 at 05:05, Scott Talbert <talbert@techie.net> wrote:
> On Mon, 9 Aug 2010, Kay Sievers wrote:
>
>> The behavior is undefined, and can only be controlled with
>> link_priority= option.
>>
>> We can't, and don't want to pretend to make any control over 'the
>> first one'. In a hotplug world, there is almost never a correct first
>> one, because everything runs in parallel.
>
> I agree with you that if two devices are hotplugged at around the same time,
> the result would be expectedly unpredictable. However, if you have your
> root partition (with a symlink established at bootup), and then hours later,
> you hotplug another device, it would seem to me that the symlink of the
> older device would be preferable to keep. Right now, the symlink for the
> original device is removed and a symlink for the new one is added.
>
> I propose a slightly different change. This changes the symlink priority
> processing when the priorities are the same. The oldest symlink is instead
> preferred, rather than the newest one.
Well, other people might want it the other way around, and want to
access the device they just plugged-in. Or they want to find the raid
device after setting it up, not the member of the raid.
Also multiple events run in parallel when a device is discovered, not
even partitions from the same device have any defined ordering here.
So, there is absolutely no guarantee about that, it's just luck in
many cases, which one wins.
As said, it does not really make sense to try to optimize anything
here, we don't have under control.
Kay
^ permalink raw reply [flat|nested] 4+ messages in thread