Differend udev names with different kernels

Differend udev names with different kernels

[Tino Keitel]

Hi,

what's the intention of /dev/disk/by-id/?

My firewire hard disk seems to have different names with different
kernels.

With 2.6.26.3, it's name is
/dev/disk/by-id/ieee1394-0030e001e0006585:00043c:0000.

With someting after 2.6.27-rc7, merged with Arjan's fastboot branch,
the disk has the same name.

With 2.6.27-rc7, it is called
/dev/disk/by-id/scsi-1WDC_WD10EACS-00D6B0_WD-WCAU41668315.

One major config difference is that 2.6.26.3 has CONFIG_FIREWIRE and
CONFIG_FIREWIRE_SBP2 set to "m", whereas the 2.6.27 kernels have set
them to "y". But that doesn't explain the difference between both
2.6.27-rc kernels.

Shouldn't these names be somewhat constant? Otherwise they would be
totally useless.

Regards,
Tino

Re: Differend udev names with different kernels

[Kay Sievers]

[-- Attachment #1: Type: text/plain, Size: 1600 bytes --]

On Wed, Sep 24, 2008 at 13:01, Tino Keitel <tino.keitel@gmx.de> wrote:
> what's the intention of /dev/disk/by-id/?
>
> My firewire hard disk seems to have different names with different
> kernels.
>
> With 2.6.26.3, it's name is
> /dev/disk/by-id/ieee1394-0030e001e0006585:00043c:0000.
>
> With someting after 2.6.27-rc7, merged with Arjan's fastboot branch,
> the disk has the same name.
>
> With 2.6.27-rc7, it is called
> /dev/disk/by-id/scsi-1WDC_WD10EACS-00D6B0_WD-WCAU41668315.

Seems, for some reason, the "ieee1394_id" attribute becomes readable
because of lucky timing, which wasn't the case before.

> One major config difference is that 2.6.26.3 has CONFIG_FIREWIRE and
> CONFIG_FIREWIRE_SBP2 set to "m", whereas the 2.6.27 kernels have set
> them to "y". But that doesn't explain the difference between both
> 2.6.27-rc kernels.

I guess, it's just a not-easy-to-reproduce timing issue with the sysfs
attribute.

> Shouldn't these names be somewhat constant? Otherwise they would be
> totally useless.

Yeah, sure they should not change like this.

We could just drop the ieee1394-* link creation entirely, if they
never worked as expected. Or we can provide it as an additional link
instead of making it skip the scsi-* link creation. Tino, care to try
if something like the attached works for your setup and creates at
least the scsi-links, and, if luckily timed, the ieee1394 links?

Stefan, ieee1394 hooks into scsi logic which, i guess, creates the
attribute _after_ event time, so udev will not see the attribute when
the device is announced. Any idea how to fix that?

Thanks,
Kay

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: ieee1394-links-fix.patch --]
[-- Type: text/x-patch; name=ieee1394-links-fix.patch, Size: 1790 bytes --]

diff --git a/rules/rules.d/60-persistent-storage.rules b/rules/rules.d/60-persistent-storage.rules
index 5218b2c..dec83cf 100644
--- a/rules/rules.d/60-persistent-storage.rules
+++ b/rules/rules.d/60-persistent-storage.rules
@@ -31,13 +31,16 @@ KERNEL=="hd*[!0-9]", IMPORT{program}="ata_id --export $tempnode"
 KERNEL=="hd*[!0-9]", ENV{ID_SERIAL}=="?*", SYMLINK+="disk/by-id/ata-$env{ID_MODEL}_$env{ID_SERIAL}"
 KERNEL=="hd*[0-9]", ENV{ID_SERIAL}=="?*", SYMLINK+="disk/by-id/ata-$env{ID_MODEL}_$env{ID_SERIAL}-part%n"
 
-KERNEL=="sd*[!0-9]|sr*", ATTRS{ieee1394_id}=="?*", ENV{ID_SERIAL}="$attr{ieee1394_id}", ENV{ID_BUS}="ieee1394"
 KERNEL=="sd*[!0-9]|sr*", ENV{ID_SERIAL}!="?*", SUBSYSTEMS=="usb", IMPORT{program}="usb_id --export %p"
 KERNEL=="sd*[!0-9]|sr*", ENV{ID_SERIAL}!="?*", IMPORT{program}="scsi_id --export --whitelisted -d $tempnode", ENV{ID_BUS}="scsi"
 KERNEL=="cciss?c[0-9]d[0-9]*", ENV{ID_SERIAL}!="?*", IMPORT{program}="scsi_id --export --whitelisted -d $tempnode", ENV{ID_BUS}="cciss"
 KERNEL=="sd*[!0-9]|sr*|cciss?c[0-9]d[0-9]*", ENV{ID_SERIAL}=="?*", SYMLINK+="disk/by-id/$env{ID_BUS}-$env{ID_SERIAL}"
 KERNEL=="sd*[0-9]|cciss*p[0-9]*", ENV{ID_SERIAL}=="?*", SYMLINK+="disk/by-id/$env{ID_BUS}-$env{ID_SERIAL}-part%n"
 
+# firewire
+KERNEL=="sd*[!0-9]|sr*", ATTRS{ieee1394_id}=="?*", SYMLINK+="disk/by-id/ieee1394-$attr{ieee1394_id}"
+KERNEL=="sd*[0-9]", ATTRS{ieee1394_id}=="?*", SYMLINK+="disk/by-id/ieee1394-$attr{ieee1394_id}-part%n"
+
 # libata compat (ata-* links, like old hd* devices did create)
 KERNEL=="sd*[!0-9]|sr*", ENV{ID_VENDOR}=="ATA", PROGRAM="ata_id $tempnode", RESULT=="?*", ENV{ID_ATA_COMPAT}="$result", SYMLINK+="disk/by-id/ata-$env{ID_ATA_COMPAT}"
 KERNEL=="sd*[0-9]", ENV{ID_ATA_COMPAT}=="?*", SYMLINK+="disk/by-id/ata-$env{ID_ATA_COMPAT}-part%n"

Re: Differend udev names with different kernels

[Stefan Richter]

Kay Sievers wrote:
> On Wed, Sep 24, 2008 at 13:01, Tino Keitel <tino.keitel@gmx.de> wrote:
>> what's the intention of /dev/disk/by-id/?
>>
>> My firewire hard disk seems to have different names with different
>> kernels.
>>
>> With 2.6.26.3, it's name is
>> /dev/disk/by-id/ieee1394-0030e001e0006585:00043c:0000.
>>
>> With someting after 2.6.27-rc7, merged with Arjan's fastboot branch,
>> the disk has the same name.

Then this is a regression of the fastboot patch or whatever.

I will watch what will happen in 2.6.28-rc.

>> With 2.6.27-rc7, it is called
>> /dev/disk/by-id/scsi-1WDC_WD10EACS-00D6B0_WD-WCAU41668315.
> 
> Seems, for some reason, the "ieee1394_id" attribute becomes readable
> because of lucky timing, which wasn't the case before.
> 
>> One major config difference is that 2.6.26.3 has CONFIG_FIREWIRE and
>> CONFIG_FIREWIRE_SBP2 set to "m", whereas the 2.6.27 kernels have set
>> them to "y". But that doesn't explain the difference between both
>> 2.6.27-rc kernels.
> 
> I guess, it's just a not-easy-to-reproduce timing issue with the sysfs
> attribute.
> 
>> Shouldn't these names be somewhat constant? Otherwise they would be
>> totally useless.
> 
> Yeah, sure they should not change like this.
> 
> We could just drop the ieee1394-* link creation entirely, if they
> never worked as expected.

They currently work.  I never heard of them not working.

Even if there were already problems now, then the necessary course of 
action would be to fix them instead of dropping them.

Or fix the fine SCSI stack already to properly export target identifiers 
and LU identifiers.  (Not going to happen because the SCSI folks just 
don't get any midlayer stuff of that sort done, ever.)


> Or we can provide it as an additional link
> instead of making it skip the scsi-* link creation.

The scsi-* link may not be unique because it may be based on unsuitable 
information generated by the SBP-2 bridge device's firmware.


> Tino, care to try
> if something like the attached works for your setup and creates at
> least the scsi-links, and, if luckily timed, the ieee1394 links?
> 
> Stefan, ieee1394 hooks into scsi logic which, i guess, creates the
> attribute _after_ event time, so udev will not see the attribute when
> the device is announced. Any idea how to fix that?

I will look into it.
-- 
Stefan Richter
-===-=--- =--= =--http://arcgraph.de/sr/

Re: Differend udev names with different kernels

[Tino Keitel]

On Thu, Sep 25, 2008 at 07:08:20 +0200, Stefan Richter wrote:
> Kay Sievers wrote:
>> On Wed, Sep 24, 2008 at 13:01, Tino Keitel <tino.keitel@gmx.de> wrote:
>>> what's the intention of /dev/disk/by-id/?
>>>
>>> My firewire hard disk seems to have different names with different
>>> kernels.
>>>
>>> With 2.6.26.3, it's name is
>>> /dev/disk/by-id/ieee1394-0030e001e0006585:00043c:0000.
>>>
>>> With someting after 2.6.27-rc7, merged with Arjan's fastboot branch,
>>> the disk has the same name.
>
> Then this is a regression of the fastboot patch or whatever.

It has the same name with 2.6.26.3 and with 2.6.27-rc7-something with
fastboot merged. So why would this be a regression? The different name
(scsi-...) happended with a vanilla 2.6.27-rc7.

Initially, my intention was to find a unique name for the hard disk,
that stays even if the disk is changed from Firewire to USB. However,
this doesn't seem to be possible with a default udev.

Regards,
Tino

Re: Differend udev names with different kernels

[Stefan Richter]

Tino Keitel wrote:

Tino, when you reply on LKML, please keep _all_ responders in a thread 
in the Cc list.  I for one am not subscribed to linux-hotplug, and I may 
easily miss a response on LKML with its hundreds of messages per day if 
I am not Cc'd.  Thanks.

> On Thu, Sep 25, 2008 at 07:08:20 +0200, Stefan Richter wrote:
>> Kay Sievers wrote:
>>> On Wed, Sep 24, 2008 at 13:01, Tino Keitel <tino.keitel@gmx.de> wrote:
>>>> what's the intention of /dev/disk/by-id/?
>>>>
>>>> My firewire hard disk seems to have different names with different
>>>> kernels.
>>>>
>>>> With 2.6.26.3, it's name is
>>>> /dev/disk/by-id/ieee1394-0030e001e0006585:00043c:0000.
>>>>
>>>> With someting after 2.6.27-rc7, merged with Arjan's fastboot branch,
>>>> the disk has the same name.
>> Then this is a regression of the fastboot patch or whatever.
> 
> It has the same name with 2.6.26.3 and with 2.6.27-rc7-something with
> fastboot merged. So why would this be a regression? The different name
> (scsi-...) happended with a vanilla 2.6.27-rc7.

I misunderstood.  (Comprehension difficulties at 0700 AM.)

It is of course intended that FireWire disks get the 
/dev/disk/by-id/ieee1394-* link.  Only this one is reliably unique.  The 
/dev/disk/scsi-* link, which I presume is generated from SCSI INQUIRY 
data, is alas often not unique if it comes from FireWire disks.

> Initially, my intention was to find a unique name for the hard disk,
> that stays even if the disk is changed from Firewire to USB. However,
> this doesn't seem to be possible with a default udev.

This is only possible with udev scripts that are customized by the user 
for each individual disk.

Dual FireWire + USB enclosures use entirely separate firmwares for their 
FireWire and USB interfaces because the protocols are so different. 
Hence there are also no unique device properties of the FireWire and USB 
side that can be generally recognized as belonging to the identical device.

An alternative though would be filesystem labels or filesystem UUIDs, if 
unique and persistent identifiers at the filesystem level rather than at 
the block device level are sufficient for your needs.
-- 
Stefan Richter
-===-=--- =--= =--http://arcgraph.de/sr/

Re: Differend udev names with different kernels

[Tino Keitel]

On Thu, Sep 25, 2008 at 23:13:19 +0200, Stefan Richter wrote:

[...]

>> Initially, my intention was to find a unique name for the hard disk,
>> that stays even if the disk is changed from Firewire to USB. However,
>> this doesn't seem to be possible with a default udev.

[...]

> An alternative though would be filesystem labels or filesystem UUIDs, if  
> unique and persistent identifiers at the filesystem level rather than at  
> the block device level are sufficient for your needs.

Not really. My initial problem was that a volume sometimes came up very
late, so that the lvm2 initscript didn't activate that volume group. So
I wanted to wait for this specific disk during boot. Meanwhile, I
created an udev rule that uses the vendor and device name, which also
has the advantage of being the same when the disk is connected via
Firewire and USB (or, should be the same at least, I didn't test USB
yet).

Regards,
Tino

Re: Differend udev names with different kernels

[Stefan Richter]

I wrote:
>> On Wed, Sep 24, 2008 at 13:01, Tino Keitel <tino.keitel@gmx.de> wrote:
>>> My firewire hard disk seems to have different names with different
>>> kernels.
>>>
>>> With 2.6.26.3, it's name is
>>> /dev/disk/by-id/ieee1394-0030e001e0006585:00043c:0000.
>>>
>>> With someting after 2.6.27-rc7, merged with Arjan's fastboot branch,
>>> the disk has the same name.
> 
> Then this is a regression of the fastboot patch or whatever.
> 
> I will watch what will happen in 2.6.28-rc.
> 
>>> With 2.6.27-rc7, it is called
>>> /dev/disk/by-id/scsi-1WDC_WD10EACS-00D6B0_WD-WCAU41668315.

Uh, sorry, I misunderstood.  It is a regression of mainline then.

> The scsi-* link may not be unique because it may be based on unsuitable
> information generated by the SBP-2 bridge device's firmware.
...
> I will look into it.
-- 
Stefan Richter
-===-=--- =--= =--http://arcgraph.de/sr/

Re: Differend udev names with different kernels

[Kay Sievers]

On Wed, Sep 24, 2008 at 22:59, Stefan Richter <stefanr@s5r6.in-berlin.de> wrote:
> I wrote:
>>>
>>> On Wed, Sep 24, 2008 at 13:01, Tino Keitel <tino.keitel@gmx.de> wrote:
>>>>
>>>> My firewire hard disk seems to have different names with different
>>>> kernels.
>>>>
>>>> With 2.6.26.3, it's name is
>>>> /dev/disk/by-id/ieee1394-0030e001e0006585:00043c:0000.
>>>>
>>>> With someting after 2.6.27-rc7, merged with Arjan's fastboot branch,
>>>> the disk has the same name.
>>
>> Then this is a regression of the fastboot patch or whatever.
>>
>> I will watch what will happen in 2.6.28-rc.
>>
>>>> With 2.6.27-rc7, it is called
>>>> /dev/disk/by-id/scsi-1WDC_WD10EACS-00D6B0_WD-WCAU41668315.
>
> Uh, sorry, I misunderstood.  It is a regression of mainline then.

Yeah, I have more reports from people, that with recent kernels, the
ieee1394-* links showed up and replaced the scsi-* links, which they
say never happended before.
We ship these rules for a long time now, so I just guessed, they never
really worked before, but as all depends on timing, it's probably not
predictable what happens. Regardless of the needed fix for scsi sysfs,
we should provide both links, I guess.

Thanks,
Kay