[ANNOUNCE] devlabel: consistent device access through symlinking

[ANNOUNCE] devlabel: consistent device access through symlinking

[Gary_Lerhaupt]

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

Attached is a program I have been working on to allow for consistent access
to storage devices.  It works by creating symlinks to actual storage device
names.  When coupled with the UUID of the disk in question, the symlink can
consistently point to the right data even if the device name changes.
Devices can thus be referenced by their symlink only and this symlink is
user-definable.  

Moreover, I've incorporated it into the current hotplug system (I did my
testing on Red Hat 7.3/Advanced Server 2.1).  You should, for example, be
able to plug your flashcard reader into your USB slot, add a symlink to it
and then use this symlink as its reference.  Remove the cardreader from USB
and the symlink should disappear.  Re-insert and the symlink will come back.
This should also work for PCMCIA devices as well as IEEE1394 (firewire).
While patches are included with this RPM, the eventual idea would be to get
the code added directly into hotplug.

The UUIDs gathered vary dependent on the device in question.  For SCSI (this
includes USB/firewire) it will attempt to search for IDS in the following
order: Page83 type 3, Page83 type 2, Page83 type 1, Page 80, Page83 type 0,
Manufacturer/Model Name.  For IDE, it only looks in /proc/ide/hd#/identify
(words 10-19, the serial number).  In both cases it will always try to
append the manufacturer/model data so that in the event that your device
does not return any UUID (eg. megaraid) you will at least be able to use
this as an ID.  However, if more than one device on your system returns the
same ID, neither will be usable with devlabel.  It is also worth noting that
USB/Firewire stuffs return the UUID of the reader and not of the storage
contained within.  This is not such a bad thing if you think about it, but
you should probably label your symlink accordingly  (eg. /dev/flashreader
instead of /dev/flashdisk1).

Also included with the RPM is an rc.sysinit patch to run devlabel on boot.
I am not quite sure I have placed this correctly and this is important if
you wish to use your symlinks within /etc/fstab.  Want to make sure that the
symlink is correct before fstab gets ahold of it.  I may also consider
writing additional code to comment out references in fstab in the event that
the symlink has been deleted because the UUID can no longer be
determined/found (maybe a "restart safefstab" parameter or something).

I'm very interested in feedback.  Thanks.

Gary Lerhaupt
ESG Linux Solutions
Dell Computer Corporation


[-- Attachment #2: devlabel-0.15-1.src.rpm --]
[-- Type: application/octet-stream, Size: 14021 bytes --]

Re: [ANNOUNCE] devlabel: consistent device access through symlinking

[Daniel Egger]

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

Am Fre, 2002-09-06 um 19.40 schrieb Gary_Lerhaupt@Dell.com:

> Attached is a program I have been working on to allow for consistent access
> to storage devices.  It works by creating symlinks to actual storage device
> names.  When coupled with the UUID of the disk in question, the symlink can
> consistently point to the right data even if the device name changes.
> Devices can thus be referenced by their symlink only and this symlink is
> user-definable.  

Except that for source RPMs sucking big time the stuff is REALLY cool!
I could also see benefits for other devices like HID where the current
ordering is done after a first come - first serve approach where the
minor device numbers follow the order the devices appear on the bus
which is quite easy to mess up and never consistent; Applying your
scheme to and-class devices also would allow to link whatever device
to a fixed device node which could solve many problems as far as
I can see.

Can you elaborate how you retrieve the IDs of a firewire or USB
controller?
 
-- 
Servus,
       Daniel

[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 189 bytes --]