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
--

[ message continues ]

Seems, for some reason, the "ieee1394_id" attribute becomes readable

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

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
[ message continues ]

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


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 

The scsi-* link may not be unique because it may be based on unsuitable 

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

[ message continues ]

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
--

[ message continues ]

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 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 

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/
--

[ message continues ]

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



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
--

[ message continues ]

-- 
Stefan Richter
-=====-==--- =--= ==--=
http://arcgraph.de/sr/
--

[ message continues ]

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
--

[ message continues ]