Re: [PATCH] minimal SAS transport class

[Douglas Gilbert <dougg@torque.net>]

Luben Tuikov wrote:
> On 08/22/05 00:55, Matt Domsch wrote:
> 
>>On Sat, Aug 20, 2005 at 12:15:41AM -0400, James.Smart@Emulex.Com wrote:
>>
>>
>>>- There are some real challenges in supporting a udev-named boot
>>> device. For the most part, it's a distro issue, which is becoming
>>> better. PS: for $10, name a 2.6 distro that uses udev out
>>> of the box for disk names and its installation. For $10 more, 
>>> can it install/boot from one?
>>
>>
>>I won't get your $10, but RHEL4 has a mechanism to specify "install
>>onto BIOS disk N", where N is typically 80h (it's an int13 number,
>>what BIOS typically boots from).  EDD in anaconda handles the mapping
>>of BIOS disk number to /dev/whatever.
> 
> 
> Hi Matt!  How is it going?
> 
> I wonder, do you think it would advantageous to provide
> another label to a disk device which includes this mapping?
> 
> (This is in lieu to the "myriad of labels" notion I've been
> talking about recently, where vendors (BIOS, Dell, disk manufacturer,
> transport layer, etc, etc, etc.) provide yet another label.  This label
> is tacked to the LU (most commonly a disk, it is *not* an FS label.))
> 
> This way, user space, or whoever, can look up the LU (disk device)
> by a label, that label or whichever one.

A note on the subject of LU labels: recent SCSI disks from
Fujitsu, Hitachi and Maxtor (but I cannot confirm this
for Seagate disks) support the REPORT and SET DEVICE
IDENTIFIER SCSI commands. These use a non-volatile
area outside a disk's lba space in which a user can
write a label (with a max length of 16, 64 (min in current
draft) or 512 (max in current draft) bytes depending
on the vendor).

I believe recent ATA disks also have a similar area where
a disk label could be written by the OS/user.

Doug Gilbert