On 11-02-04 02:36 PM, scameron@xxxxxxxxxxxxxxxxxx wrote:
Would it be a reasonable idea to add some sort of unique_id attribute
to scsi devices in the mid layer?
For example, sg_inq, from sg3_utils, will print out a serial number:
[root@localhost scameron]# sg_inq /dev/sda
standard INQUIRY:
PQual=0 Device_type=0 RMB=0 version=0x05 [SPC-3]
[AERC=0] [TrmTsk=0] NormACA=0 HiSUP=0 Resp_data_format=2
SCCS=0 ACC=0 TPGS=0 3PC=0 Protect=0 BQue=0
EncServ=0 MultiP=0 [MChngr=0] [ACKREQQ=0] Addr16=0
[RelAdr=0] WBus16=0 Sync=0 Linked=0 [TranDis=0] CmdQue=1
length=56 (0x38) Peripheral device type: disk
Vendor identification: HP
Product identification: LOGICAL VOLUME
Product revision level: 3.66
Unit serial number: 50014380065020C0
And there's also some stuff in page 0x83 on some devices which might
be useful as suck an identifier:
[root@localhost scameron]# sg_inq --page 0x83 /dev/sda
VPD INQUIRY: Device Identification page
Designation descriptor number 1, descriptor length: 20
designator_type: NAA, code_set: Binary
associated with the addressed logical unit
NAA 6, IEEE Company_id: 0x508b
Vendor Specific Identifier: 0x1001ce88b
Vendor Specific Identifier Extension: 0x746f381eedf6577
[0x600508b1001ce88b0746f381eedf6577]
Designation descriptor number 2, descriptor length: 8
designator_type: vendor specific [0x0], code_set: Binary
associated with the addressed logical unit
00 00 00 00 00 ....
[root@localhost scameron]#
The hpsa driver, for example, currently exports a "unique_id"
attribute itself for disks, which is the same data reported by
inquire page 0x83.
[root@localhost 0:0:0:1]# pwd
/sys/bus/scsi/devices/0:0:0:1
[root@localhost 0:0:0:1]# cat unique_id
600508B1001CE88B0746F381EEDF6577
It occurs to me that maybe something
like that would be useful for all disks serviced by the scsi mid layer.
For example, kdump userland stuff, as typically implemented,
has a very small ramdisk which it operates from, and has a fairly
simple minded way of recognizing which disk is which (e.g. looks at
vendor, model, rev, and type attributes, arguably not a very good way
to do it, as just flashing firmware on a drive will change the rev, but
won't mean the disk is not the same disk, for example, and likewise, all
disks on a given Smart Array will carry the same vendor/model/rev/type,
and type? Type is always going to be zero for a disk anyhow.)
So kdump needs some kind of a unique_id to help it out, but would prefer
not to carry around e.g. sg_inq in the kdump initrd (so you may ask
"stuffing it in the kernel is a better idea?") Well, _if_ the LLDs are
typically already getting this info (as in the case of hpsa and cciss
at least) maybe they should have some standard way of informing the
mid layer, so the midlayer could expose this attribute in a standard way?
Or, maybe the mid layer could send down the necessary inquiries to get
the information itself with no interface changes needed?
Well, this seems like such an obvious idea, that the mere fact that it
is not already implemented makes me think there may be some good reason
why not.
Yes, indeed :-)
The problem is those pesky little storage devices that
(ab)use the SCSI command set (e.g. some USB keys). Some of
them lock up when given anything other than a bog standard
INQUIRY command requesting a 36 byte response with
EVPD=0. After the lock up such devices typically need a
power cycle to come back to life, then if the OS sends them
the same command again that locked them up ... you
probably get the idea.
Redmond seems to like globally unique identifiers (GUIDs)
for storage devices, I wonder how they handle this problem.
A heuristic based in the transport may be one approach.
Doug Gilbert
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
