Re: [RFC] Persistent naming of scsi devices

Re: [RFC] Persistent naming of scsi devices

[Christoph Hellwig]

On Mon, Apr 08, 2002 at 09:18:44AM -0600, sullivan wrote:
> I would welcome any thoughts, comments, or suggestions.

What is the rationale for doing this?  I think we should rather get people
to actually use the UUID= option to mount..

[RFC] Persistent naming of scsi devices

[sullivan]

I have been working on a prototype to allow the persistent naming of scsi devices across boots. The prototype attempts to address the namespace slippage that occurs when names are assigned based on discovery order or topology, and a hardware configuration change occurs. It does this by assigning names based on the characteristics of the device.

The prototype and more detailed info can be found at:
http://oss.software.ibm.com/devreg/

The prototype utilizes 3 components:
1. driverfs to collect and publish the characteristics of the device
2. devfs to generate insertion and removal events
3. devfsd library to handle the events, parse driverfs, and apply the naming logic.

I am also currently working on a non devfs version that uses /sbin/hotplug as the event generation mechanism.

I would welcome any thoughts, comments, or suggestions.

Re: [RFC] Persistent naming of scsi devices

[Matthew Jacob]

On Mon, 8 Apr 2002, Christoph Hellwig wrote:

> On Mon, Apr 08, 2002 at 09:18:44AM -0600, sullivan wrote:
> > I would welcome any thoughts, comments, or suggestions.
> 
> What is the rationale for doing this?  I think we should rather get people
> to actually use the UUID= option to mount..
right on!

RE: [RFC] Persistent naming of scsi devices

[Matt_Domsch]

> I have been working on a prototype to allow the persistent 
> naming of scsi devices across boots. The prototype attempts 
> to address the namespace slippage that occurs when names are 
> assigned based on discovery order or topology, and a hardware 
> configuration change occurs. It does this by assigning names 
> based on the characteristics of the device.

> I think we should rather get people
> to actually use the UUID= option to mount..

Agreed.  Andreas' swap partition patches are needed here too.

The only other case this is tricky is at clean-disk install time, before any
UUIDs are available, when you've got disks on multiple controllers.  Here,
the BIOS and Linux have no way to communicate which device they each think
is the boot device.  Some BIOSs (like on Adaptec 39160 add-in cards, and
7890/7899 embedded controllers on Dell servers) provide BIOS Enhanced Disk
Device Services 3.0 (EDD 3.0), which provides an extension to BIOS int13
AX=48 which specifies, for BIOS's idea of device 80, 81, ..., the PCI
bus/dev/fn and type (SCSI/IDE,...) Not all BIOSs yet provide such. :-(  But,
having that, Linux could then compare its similar mapping, and get right
without manual intervention what disk is the boot disk.

-Matt
--
Matt Domsch
Sr. Software Engineer
Dell Linux Solutions www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com
#1 US Linux Server provider for 2001!

Re: [RFC] Persistent naming of scsi devices

[James Bottomley]

On Mon, Apr 08, 2002 at 09:18:44AM -0600, sullivan wrote:
> I would welcome any thoughts, comments, or suggestions.

hch@infradead.org said:
> What is the rationale for doing this?  I think we should rather get
> people to actually use the UUID= option to mount.. 

I think, actually, that this feature is aimed more generally.  UUID really 
only works for filesystems that support it (and in Linux, I believe, this is 
currently only ext2/3 for 2.4 plus reiser in 2.5).  A persistent device 
binding would be of use to people adopting Linux in their SAN enterprise who 
were not (at least initially) planning to convert all their filesystems over 
to Linux ones.  It would also work for raw devices, which don't have an 
underlying filesystem to store the UUID.

I'm not sure we want to get into writing a UUID to a "safe" place on a device 
for such legacy filesystem types (especially as most administrators loathe 
this feature in NT).

The proposal for the device naming project says 

"[...] Some of the characteristics examined include information returned from 
the SCSI Inquiry command, and the labels found on the disks partitions."

which implies to me that you can bind by UUID if desired.

One of the things I'm not so keen on in the proposed patch is that there is a 
large amount of code placed in the kernel for determining the vital product 
data IDs.  For the scheme to be fully flexible, it would be much better to 
move this out to user land, using the /dev/sg pipe into the device, so that 
determining and using the device "characteristics" can be much more flexible.  
Hotplug is probably more useful to this type of user level based configuration 
than devfs et al.

James

Re: [RFC] Persistent naming of scsi devices

[Oliver Neukum]

On Monday 08 April 2002 17:04, Christoph Hellwig wrote:
> On Mon, Apr 08, 2002 at 09:18:44AM -0600, sullivan wrote:
> > I would welcome any thoughts, comments, or suggestions.
>
> What is the rationale for doing this?  I think we should rather get people
> to actually use the UUID= option to mount..

UUID cannot solve the problem. It identifies filesystems.
There's a need to identify devices. Not everything
is a hard drive with a filesystem on it.

	Regards
		Oliver

Re: [RFC] Persistent naming of scsi devices

[Christoph Hellwig]

On Mon, Apr 08, 2002 at 07:51:59PM +0200, Oliver Neukum wrote:
> On Monday 08 April 2002 17:04, Christoph Hellwig wrote:
> > On Mon, Apr 08, 2002 at 09:18:44AM -0600, sullivan wrote:
> > > I would welcome any thoughts, comments, or suggestions.
> >
> > What is the rationale for doing this?  I think we should rather get people
> > to actually use the UUID= option to mount..
> 
> UUID cannot solve the problem. It identifies filesystems.

Or volumes..

Re: [RFC] Persistent naming of scsi devices

[Matthew Jacob]

On Mon, 8 Apr 2002, Oliver Neukum wrote:

> On Monday 08 April 2002 17:04, Christoph Hellwig wrote:
> > On Mon, Apr 08, 2002 at 09:18:44AM -0600, sullivan wrote:
> > > I would welcome any thoughts, comments, or suggestions.
> >
> > What is the rationale for doing this?  I think we should rather get people
> > to actually use the UUID= option to mount..
> 
> UUID cannot solve the problem. It identifies filesystems.
> There's a need to identify devices. Not everything
> is a hard drive with a filesystem on it.
> 

Then let's use WWPN/WWNS and/or drive serial #'s to do UUIDs for devices.

-amtt

Re: [RFC] Persistent naming of scsi devices

[Patrick Mansfield]

On Mon, Apr 08, 2002 at 11:34:26AM -0500, James Bottomley wrote:
> On Mon, Apr 08, 2002 at 09:18:44AM -0600, sullivan wrote:
> > I would welcome any thoughts, comments, or suggestions.

> One of the things I'm not so keen on in the proposed patch is that there is a 
> large amount of code placed in the kernel for determining the vital product 
> data IDs.  For the scheme to be fully flexible, it would be much better to 
> move this out to user land, using the /dev/sg pipe into the device, so that 
> determining and using the device "characteristics" can be much more flexible.  
> Hotplug is probably more useful to this type of user level based configuration 
> than devfs et al.
> 
> James

James -

We could have a set of interfaces to get a SCSI UUID, and then have
hotplug tell us which interface (or module?) to use. That way we don't
require sg.

The device_list[] (black/white list) should also come from user land.
Maybe hotplug could get the device_list[] characteristics, including
the UUID method for the device.

I'd also like a uuid stored in Scsi_Device for multi-path support in the
mid-layer (independent of how it's set). This uuid could not be stored
in the partition or as part of the file system.

-- Patrick

Re: [RFC] Persistent naming of scsi devices

[James Bottomley]

mjacob@feral.com said:
> Then let's use WWPN/WWNS and/or drive serial #'s to do UUIDs for
> devices. 

That's what the persistent binding proposal that started all this uses.  
However, these strings are incredibly long at best and (in spite of what the 
SCSI spec says) sometimes include non-printing characters, so you don't 
necessarily want to be passing them on the command line.

James

Re: [RFC] Persistent naming of scsi devices

[Matthew Jacob]

A discussion about this kind of stuff went on at Sun in 1989. You want
unambigious physical attribute names that are absolutely precise- this is what
you get with, say, OpenBoot pathnames. But you don't want people to have to
deal with them because they're unwieldy. Instead, you want 'friendly'
names. For the OBP discussions back at Sun, this ended up as the 'devalias'
command for the prom, so 'Fred' could be /iommu@foo/sbus@bar/disk@wank, etc.

For the current discussion, it seems to me that unlabelled/unimported
disks/volumes (i.e., ones w/o a UUID) still can be named unambiguosly by the
unwieldy names because you're likely to put a UUID on them very very
quickly. Furthermore, a minor amount of effort in userland tools can make the
manipulation of said names not as much of a problem.

Sorry if I came into the discussion late.

-matt


On Mon, 8 Apr 2002, James Bottomley wrote:

> mjacob@feral.com said:
> > Then let's use WWPN/WWNS and/or drive serial #'s to do UUIDs for
> > devices. 
> 
> That's what the persistent binding proposal that started all this uses.  
> However, these strings are incredibly long at best and (in spite of what the 
> SCSI spec says) sometimes include non-printing characters, so you don't 
> necessarily want to be passing them on the command line.
> 
> James
> 
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [RFC] Persistent naming of scsi devices

[Tigran Aivazian]

On Mon, 8 Apr 2002, Christoph Hellwig wrote:

> On Mon, Apr 08, 2002 at 09:18:44AM -0600, sullivan wrote:
> > I would welcome any thoughts, comments, or suggestions.
>
> What is the rationale for doing this?  I think we should rather get people
> to actually use the UUID= option to mount..

Imagine an appliance serving out data from filesystems but also directly
connected to a tape library (or, even better, many such libraries),
obviously for direct backups.  After reshuffling devices in the library
(e.g. by breaking some of them :) Linux will reorder the tape devices in
the way it finds them which will completely screw up the windows client
software that is controlling the actual backup. So persistent naming of
such devices is a good idea but to implement it is far from trivial. I am
assuming the folks at IBM did this "non-trivial bit".

Regards,
Tigran

Re: [RFC] Persistent naming of scsi devices

[James Bottomley]

mjacob@feral.com said:
> For the current discussion, it seems to me that unlabelled/unimported
> disks/volumes (i.e., ones w/o a UUID) still can be named unambiguosly
> by the unwieldy names because you're likely to put a UUID on them very
> very quickly. Furthermore, a minor amount of effort in userland tools
> can make the manipulation of said names not as much of a problem.

I agree, but there are the edge cases where you can't put a UUID on them.

I think, however, that what the discussion is showing us is that there is no 
one universal way to get a unique name for a volume, so what we want is some 
type of pluggable infrastructure which allows us to construct a unique name.

As far as persistent binding goes, I think having the ability to persistently 
bind the unique name to a device is a useful feature for those of us who don't 
want to know what the actual unique name is (or who want a nicer name).

However, nothing should prevent you from passing the name as a string to mount 
instead of using persistent binding (even if the string turns out to have to 
be a set of hex digits).  Perhaps we could even have a user level table of 
nice UUID to unwieldy unique name mapping, and you can use a user specified 
UUID without having to put anything on the device or partition.

The summary so far, as I see it, is

1) persistent binding might be a user friendly way of uniquely identifying 
devices
2) UUID doesn't solve the problem because not everything has one
3) ditto for WWN or EVPID

Another wrinkle is that UUID is partition specific, but WWN etc. are device 
specific.

James

Re: [RFC] Persistent naming of scsi devices

[James Bottomley]

patmans@us.ibm.com said:
> We could have a set of interfaces to get a SCSI UUID, and then have
> hotplug tell us which interface (or module?) to use. That way we don't
> require sg.

I'm in two minds about this one.  Deciding exactly what constitutes the UUID 
for a particular device can be non trivial.  Usually you have to probe for the 
supported vital product pages, and if they have the WWN one use that otherwise 
fall back to the (less guaranteed to be unique) SCSI-2 serial number page or 
finally make something up dependent on what unique numbers you can get from 
the device.

It makes sense to me that this type of complex rule (of thumb almost) based 
lookup is best done from user level by doing the explicit SCSI commands if 
necessary.

However, I'm biased.  From a philosophical point of view, I like the hotplug 
approach because it allows us to eject a lot of the use once initialisation 
code into user space from the kernel.

> The device_list[] (black/white list) should also come from user land.
> Maybe hotplug could get the device_list[] characteristics, including
> the UUID method for the device.

> I'd also like a uuid stored in Scsi_Device for multi-path support in
> the mid-layer (independent of how it's set). This uuid could not be
> stored in the partition or as part of the file system. 

If we can come up with a nice, general mechanism, there's no reason why it 
cannot apply outside the SCSI system, so I wouldn't necessarily tie it to 
Scsi_Devce.  More likely (and actually what the persistent binding begins) is 
to tie it to the concept of the Mochel internal device tree.

James

Re: [RFC] Persistent naming of scsi devices

[Martin Peschke3]

> mjacob@feral.com said:
> > Then let's use WWPN/WWNS and/or drive serial #'s to do UUIDs for
> > devices.
>
> That's what the persistent binding proposal that started all this uses.
> However, these strings are incredibly long at best and (in spite of what
the
> SCSI spec says) sometimes include non-printing characters, so you don't
> necessarily want to be passing them on the command line.
>
> James

That's true of course for Fibre Channel WWNs (64 bit).
Such identifiers might be shorter (or longer)
depending on the considered interface.
What could be used for good old parallel attachments?

I would suggest to circumvent problems with non-printing
characters by means of hexadecimal notation
(e.g. 0x5007890000a11753 representing a WWN).


Mit freundlichen Grüßen / with kind regards

Martin Peschke

IBM Deutschland Entwicklung GmbH
Linux for eServer Development
Phone: +49-(0)7031-16-2349



-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] Persistent naming of scsi devices

[Eddie Williams]

On Monday 08 April 2002 11:18 am, sullivan wrote:
> I have been working on a prototype to allow the persistent naming of scsi
> devices across boots. The prototype attempts to address the namespace
> slippage that occurs when names are assigned based on discovery order or
> topology, and a hardware configuration change occurs. It does this by
> assigning names based on the characteristics of the device.
>
> The prototype and more detailed info can be found at:
> http://oss.software.ibm.com/devreg/


Looks good.  As your README acknowledges one problem is that not all devices 
support the pages 0x80 and 0x83.

A quick scan of the code looks like you will work well with the "good" 
devices.  :-)

Several cases you might want to consider for "bad" devices:
- devices that don't support 0x00 and return standard inquiry data instead!
- devices that don't support 0x00 but do support 0x80

For the first case you can snoop the return data from 0x00 to see if it looks 
"good" versus looks like standard inquiry.

For the second case if 0x00 fails go ahead and try 0x80 anyway.

Eddie

Re: [RFC] Persistent naming of scsi devices

[Matthew Jacob]

> mjacob@feral.com said:
> > For the current discussion, it seems to me that unlabelled/unimported
> > disks/volumes (i.e., ones w/o a UUID) still can be named unambiguosly
> > by the unwieldy names because you're likely to put a UUID on them very
> > very quickly. Furthermore, a minor amount of effort in userland tools
> > can make the manipulation of said names not as much of a problem.
> 
> I agree, but there are the edge cases where you can't put a UUID on them.
> 
> I think, however, that what the discussion is showing us is that there is no 
> one universal way to get a unique name for a volume, so what we want is some 
> type of pluggable infrastructure which allows us to construct a unique name.

Fair enough!

I would resist constructing names with addresses that can change easily (e.g.,
PortIDs or SCSI Targets, or device instance numbers based on probe order).

-matt

Re: [RFC] Persistent naming of scsi devices

[Matthew Jacob]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=X-UNKNOWN, Size: 1435 bytes --]


It's more than just a WWN- it really has to be the pair of WWNN/WWPN (node &&
port name) as you can have, e.g., a dual ported disk with the same WWNN but
different WWPNs.

On Mon, 8 Apr 2002, Martin Peschke3 wrote:

> 
> 
> > mjacob@feral.com said:
> > > Then let's use WWPN/WWNS and/or drive serial #'s to do UUIDs for
> > > devices.
> >
> > That's what the persistent binding proposal that started all this uses.
> > However, these strings are incredibly long at best and (in spite of what
> the
> > SCSI spec says) sometimes include non-printing characters, so you don't
> > necessarily want to be passing them on the command line.
> >
> > James
> 
> That's true of course for Fibre Channel WWNs (64 bit).
> Such identifiers might be shorter (or longer)
> depending on the considered interface.
> What could be used for good old parallel attachments?
> 
> I would suggest to circumvent problems with non-printing
> characters by means of hexadecimal notation
> (e.g. 0x5007890000a11753 representing a WWN).
> 
> 
> Mit freundlichen Grüßen / with kind regards
> 
> Martin Peschke
> 
> IBM Deutschland Entwicklung GmbH
> Linux for eServer Development
> Phone: +49-(0)7031-16-2349
> 
> 
> 
> 

-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] Persistent naming of scsi devices

[Martin Peschke3]

> It's more than just a WWN- it really has to be
> the pair of WWNN/WWPN (node && port name) as you
> can have, e.g., a dual ported disk with the same WWNN but
> different WWPNs.

Ok, I thought of WWPN and that it would be sufficient to identify the
target side of a link, isn't it?
Do you really need a pair of WWNN/WWPN, i.e. identical WWPNs might
exist considering different WWNNs?


Mit freundlichen Grüßen / with kind regards

Martin Peschke

IBM Deutschland Entwicklung GmbH
Linux for eServer Development
Phone: +49-(0)7031-16-2349


Matthew Jacob <mjacob@feral.com>@vger.kernel.org on 04/08/2002 10:45:33 PM

Please respond to mjacob@feral.com

Sent by:    linux-scsi-owner@vger.kernel.org


To:    Martin Peschke3/Germany/IBM@IBMDE
cc:    James Bottomley <James.Bottomley@steeleye.com>, Oliver Neukum
       <oliver@neukum.org>, Christoph Hellwig <hch@infradead.org>, sullivan
       <sullivan@austin.ibm.com>, linux-scsi@vger.kernel.org
Subject:    Re: [RFC] Persistent naming of scsi devices




It's more than just a WWN- it really has to be the pair of WWNN/WWPN (node
&&
port name) as you can have, e.g., a dual ported disk with the same WWNN but
different WWPNs.

On Mon, 8 Apr 2002, Martin Peschke3 wrote:

>
>
> > mjacob@feral.com said:
> > > Then let's use WWPN/WWNS and/or drive serial #'s to do UUIDs for
> > > devices.
> >
> > That's what the persistent binding proposal that started all this uses.
> > However, these strings are incredibly long at best and (in spite of
what
> the
> > SCSI spec says) sometimes include non-printing characters, so you don't
> > necessarily want to be passing them on the command line.
> >
> > James
>
> That's true of course for Fibre Channel WWNs (64 bit).
> Such identifiers might be shorter (or longer)
> depending on the considered interface.
> What could be used for good old parallel attachments?
>
> I would suggest to circumvent problems with non-printing
> characters by means of hexadecimal notation
> (e.g. 0x5007890000a11753 representing a WWN).
>
>
> Mit freundlichen Grüßen / with kind regards
>
> Martin Peschke
>
> IBM Deutschland Entwicklung GmbH
> Linux for eServer Development
> Phone: +49-(0)7031-16-2349
>
>
>
>

-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html



-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] Persistent naming of scsi devices

[Matthew Jacob]

On Tue, 9 Apr 2002, Martin Peschke3 wrote:

> > It's more than just a WWN- it really has to be
> > the pair of WWNN/WWPN (node && port name) as you
> > can have, e.g., a dual ported disk with the same WWNN but
> > different WWPNs.
> 
> Ok, I thought of WWPN and that it would be sufficient to identify the
> target side of a link, isn't it? Do you really need a pair of WWNN/WWPN,
> i.e. identical WWPNs might exist considering different WWNNs?

If the numbering is NAA=2 (2 in the top nibble), you can always derive the
WWNN from the WWPN. But that's only true for NAA=2.

In *practice*, WWPN might be enough,  but if we're doing things that formally
and fully ID a device, and considering that iSCSI identifiers are 255 bytes or
better, two 64 bit ids for Fibre Channel devices is not unreasonable to allow
for.

-matt

Re: [RFC] Persistent naming of scsi devices

[Douglas Gilbert]

James Bottomley wrote:
> 
> patmans@us.ibm.com said:
> > We could have a set of interfaces to get a SCSI UUID, and then have
> > hotplug tell us which interface (or module?) to use. That way we don't
> > require sg.
> 
> I'm in two minds about this one.  Deciding exactly what constitutes the UUID
> for a particular device can be non trivial.  Usually you have to probe for the
> supported vital product pages, and if they have the WWN one use that otherwise
> fall back to the (less guaranteed to be unique) SCSI-2 serial number page or
> finally make something up dependent on what unique numbers you can get from
> the device.
> 
> It makes sense to me that this type of complex rule (of thumb almost) based
> lookup is best done from user level by doing the explicit SCSI commands if
> necessary.
> 
> However, I'm biased.  From a philosophical point of view, I like the hotplug
> approach because it allows us to eject a lot of the use once initialisation
> code into user space from the kernel.

Interesting discussion.

To see what the hotplug subsystem approach might look like,
see http://www.torque.net/scsi/scsimon.html . This is a
proposed scsi subsystem upper level driver (gathering dust). 
What sets it apart from the others is that it is not device
based. It has a single (misc) device name and can be thought 
of as a window through to the scsi mid level. It supplies 
hotplug alerts whenever a scsi device is attached or detached.
[Unfortunately scsi hosts being registered or unregistered
does not cause hotplug alerts.] Attaches and detaches are
given event numbers (ascending sequence) and a time_since_boot.

That said, I like the devfs/devfsd approach as well.
 
> > The device_list[] (black/white list) should also come from user land.
> > Maybe hotplug could get the device_list[] characteristics, including
> > the UUID method for the device.
> 
> > I'd also like a uuid stored in Scsi_Device for multi-path support in
> > the mid-layer (independent of how it's set). This uuid could not be
> > stored in the partition or as part of the file system.
> 
> If we can come up with a nice, general mechanism, there's no reason why it
> cannot apply outside the SCSI system, so I wouldn't necessarily tie it to
> Scsi_Devce.  More likely (and actually what the persistent binding begins) is
> to tie it to the concept of the Mochel internal device tree.

In Patrick Mansfield's and my report_lun/twin_inquiry patch
the full INQUIRY response (evpd=0 cmdtt=0) is placed in
Scsi_Device. It could be useful to make that available 
(in ascii-hex) via driverfs/hot_plug to the user space.

Eric's point is a good one about dirty INQUIRY data. This
is especially the case with what might be a large
group of "scsi" devices that linux needs to cope with:
usb2 and ieee1394 talking to an external ATA disk. For
the same Maxtor disk one INQUIRY (1394) tells me that it
is a scsi 6 compliant device while the other INQUIRY (usb2)
truncates the response at 28 bytes. I'm pretty sure they ignore
the evpd bit as well.


I'm attempting to get this patch working against 2.5.7-dj3
(as it has captured most of the good patches from the list
that haven't made it any further to date). There is a long
way to go but here are some notes:
  - driverfs is documented in:
     Documentation/driver-model.txt
     Documentation/filesystems/driverfs.txt
  - driverfs in built into 2.5 kernels but needs to be
    mounted. The documentation uses "/devices" as a
    mount point; driverfs seems more comfortable with me:
      mkdir /driverfs ; mount -t driverfs none /driverfs

Doug Gilbert

Re: [RFC] Persistent naming of scsi devices

[Kurt Garloff]

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

Hi,

just reading this discussion, I hope you all are aware of scsidev, which
provides some of the functionality needed.
Apart from allowing you to specify devces according to the bus topology
(just as devfs does), it also allows for aliases, based on various things,
such as names, device types, model or serial numbers (got from INQUIRY
with page code 0x80).
It may miss some mechanisms to deal with devices without this serial no,
e.g., but in general I do not really see why it would not be useable.
http://www.garloff.de/kurt/linux/scsidev/

Regards,
-- 
Kurt Garloff  <garloff@suse.de>                          Eindhoven, NL
GPG key: See mail header, key servers         Linux kernel development
SuSE Linux AG, Nuernberg, DE                            SCSI, Security

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: [RFC] Persistent naming of scsi devices

[sullivan]

On Mon, Apr 08, 2002 at 08:22:57PM -0400, Douglas Gilbert wrote:
> James Bottomley wrote:
> > 
> > patmans@us.ibm.com said:
> > > We could have a set of interfaces to get a SCSI UUID, and then have
> > > hotplug tell us which interface (or module?) to use. That way we don't
> > > require sg.
> > 
> > I'm in two minds about this one.  Deciding exactly what constitutes the UUID
> > for a particular device can be non trivial.  Usually you have to probe for the
> > supported vital product pages, and if they have the WWN one use that otherwise
> > fall back to the (less guaranteed to be unique) SCSI-2 serial number page or
> > finally make something up dependent on what unique numbers you can get from
> > the device.
> > 
> > It makes sense to me that this type of complex rule (of thumb almost) based
> > lookup is best done from user level by doing the explicit SCSI commands if
> > necessary.
> > 
> > However, I'm biased.  From a philosophical point of view, I like the hotplug
> > approach because it allows us to eject a lot of the use once initialisation
> > code into user space from the kernel.
> 
> Interesting discussion.
> 
> To see what the hotplug subsystem approach might look like,
> see http://www.torque.net/scsi/scsimon.html . This is a
> proposed scsi subsystem upper level driver (gathering dust). 
> What sets it apart from the others is that it is not device
> based. It has a single (misc) device name and can be thought 
> of as a window through to the scsi mid level. It supplies 
> hotplug alerts whenever a scsi device is attached or detached.
> [Unfortunately scsi hosts being registered or unregistered
> does not cause hotplug alerts.] Attaches and detaches are
> given event numbers (ascending sequence) and a time_since_boot.
> 
> That said, I like the devfs/devfsd approach as well.
>  
Thanks Doug. I've taken a look at it looks like it would work very well in providing the event generation support in the non devfs case.


> > > The device_list[] (black/white list) should also come from user land.
> > > Maybe hotplug could get the device_list[] characteristics, including
> > > the UUID method for the device.
> > 
> > > I'd also like a uuid stored in Scsi_Device for multi-path support in
> > > the mid-layer (independent of how it's set). This uuid could not be
> > > stored in the partition or as part of the file system.
> > 
> > If we can come up with a nice, general mechanism, there's no reason why it
> > cannot apply outside the SCSI system, so I wouldn't necessarily tie it to
> > Scsi_Devce.  More likely (and actually what the persistent binding begins) is
> > to tie it to the concept of the Mochel internal device tree.
> 
Patrick Mochel had mentioned before that he was looking at providing a unique identifier field as part of the common driverfs infrastructure. I'll check and see what his current thoughts are.

> In Patrick Mansfield's and my report_lun/twin_inquiry patch
> the full INQUIRY response (evpd=0 cmdtt=0) is placed in
> Scsi_Device. It could be useful to make that available 
> (in ascii-hex) via driverfs/hot_plug to the user space.
Sounds good. I'll take a look at the patch and see about adding the driverfs implementation needed to support it.

> 
> Eric's point is a good one about dirty INQUIRY data. This
> is especially the case with what might be a large
> group of "scsi" devices that linux needs to cope with:
> usb2 and ieee1394 talking to an external ATA disk. For
> the same Maxtor disk one INQUIRY (1394) tells me that it
> is a scsi 6 compliant device while the other INQUIRY (usb2)
> truncates the response at 28 bytes. I'm pretty sure they ignore
> the evpd bit as well.
> 
> 
> I'm attempting to get this patch working against 2.5.7-dj3
> (as it has captured most of the good patches from the list
> that haven't made it any further to date). There is a long
> way to go but here are some notes:
>   - driverfs is documented in:
>      Documentation/driver-model.txt
>      Documentation/filesystems/driverfs.txt
>   - driverfs in built into 2.5 kernels but needs to be
>     mounted. The documentation uses "/devices" as a
>     mount point; driverfs seems more comfortable with me:
>       mkdir /driverfs ; mount -t driverfs none /driverfs
> 
> Doug Gilbert

Re: [RFC] Persistent naming of scsi devices

[sullivan]

On Mon, Apr 08, 2002 at 02:17:42PM -0500, James Bottomley wrote:
> patmans@us.ibm.com said:
> > We could have a set of interfaces to get a SCSI UUID, and then have
> > hotplug tell us which interface (or module?) to use. That way we don't
> > require sg.
> 
> I'm in two minds about this one.  Deciding exactly what constitutes the UUID 
> for a particular device can be non trivial.  Usually you have to probe for the 
> supported vital product pages, and if they have the WWN one use that otherwise 
> fall back to the (less guaranteed to be unique) SCSI-2 serial number page or 
> finally make something up dependent on what unique numbers you can get from 
> the device.
> 
> It makes sense to me that this type of complex rule (of thumb almost) based 
> lookup is best done from user level by doing the explicit SCSI commands if 
> necessary.
> 
> However, I'm biased.  From a philosophical point of view, I like the hotplug 
> approach because it allows us to eject a lot of the use once initialisation 
> code into user space from the kernel.
> 
> > The device_list[] (black/white list) should also come from user land.
> > Maybe hotplug could get the device_list[] characteristics, including
> > the UUID method for the device.
> 
> > I'd also like a uuid stored in Scsi_Device for multi-path support in
> > the mid-layer (independent of how it's set). This uuid could not be
> > stored in the partition or as part of the file system. 
> 
> If we can come up with a nice, general mechanism, there's no reason why it 
> cannot apply outside the SCSI system, so I wouldn't necessarily tie it to 
> Scsi_Devce.  More likely (and actually what the persistent binding begins) is 
> to tie it to the concept of the Mochel internal device tree.

I think this is the decision that is the most difficult. Setting up nodes on driverfs provides a consistent location and format (if we are careful) for surfacing information on devices. I find it much more difficult to keep up with where stuff is and what format it's in in /proc. Also, I must confess that keeping track of what userland utilites to use to collect various pieces of device information strains my limited memory cells. Of course this comes at the cost of extra code in the kernel.

> 
> James
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] Persistent naming of scsi devices

[Rick Stevens]

Martin Peschke3 wrote:

<much stuff snipped>

I'm going to wade in here.  Based on my experiences on many other
Unixish systems, wouldn't it be simply better to number the things
based on controller position, SCSI ID, LUN and partition?  This
has been called "CTL" format in various documents, and many systems
use this method such as Sun, DG AvIIons, DEC, HP and a host of others.

E.g. "/dev/dsk/c0t1d2s3" is controller 0 (first SCSI controller seen on
the bus), target ID 1, LUN 2, partition (slice) 3.  Simple, unambiguous
and repeatable.

I understand that other devices may be seen on the PCI if you add or
remove cards.  Under this scheme, controller 0 is the first (lowest
slot number) unit found.  The next one would be controller 1.  Even
if you were to stuff, say, a video card in there, these would _still_
be the first SCSI cards found.  The only time a change would occur
is if a SCSI card was installed in a lower slot number or between
other SCSI controllers (and only then if the original cards were
left in) or if the ORDER of the cards was changed in the bus.

As I said, other people smarter than I seem to think it makes sense.
Why not Linux?  It's silly to smush things together just to satisfy a
bizzare craving to have a list of devices with no "holes" in it.
Besides "fsck"ing or "mkfs"ing drives, how often do you refer to them
by their names in "/dev", anyway?

This would also work for tape drives.  However, they're rooted at
/dev/stape rather than /dev/dsk.

At boot, you could create more mnemonic names as symbolic links to the
CTL names if you wish (as is done with /dev/cdrom and such), but if
you absolutely want to talk to the SAME DEVICE, you use the CTL name.

Just adding my $0.02.  We now return you to your regularly scheduled
arguments.

----------------------------------------------------------------------
- Rick Stevens, SSE, VitalStream, Inc.      rstevens@vitalstream.com -
- 949-743-2010 (Voice)                    http://www.vitalstream.com -
-                                                                    -
-          su -; find / -name someone -exec touch \{\} \;            -
-                          - The UNIX way of touching someone        -
----------------------------------------------------------------------

Re: [RFC] Persistent naming of scsi devices

[Bryan Henderson]

>E.g. "/dev/dsk/c0t1d2s3" is controller 0 (first SCSI controller seen on
>the bus), target ID 1, LUN 2, partition (slice) 3.  Simple, unambiguous
>and repeatable.

For many purposes, you're right, and for that reason devfs already does 
this.  However, in some cases these are not repeatable.  A volume that is 
LUN 5 today could be LUN 7 tomorrow.  This is true in heavy-duty disk 
storage subsystems that let you create and destroy logical units on the 
fly, using the physical medium as a resource pool.  And what is LUN 5 for 
me could be LUN 7 for you at the same time, if we're both wired into the 
same storage subsystem.

Re: [RFC] Persistent naming of scsi devices

[Matthew Jacob]

On Tue, 9 Apr 2002, Rick Stevens wrote:

> Martin Peschke3 wrote:
> 
> <much stuff snipped>
> 
> I'm going to wade in here.  Based on my experiences on many other
> Unixish systems, wouldn't it be simply better to number the things
> based on controller position, SCSI ID, LUN and partition? 

Address has become a very non-persistent thing.


> has been called "CTL" format in various documents, and many systems
> use this method such as Sun, DG AvIIons, DEC, HP and a host of others.
> 
> E.g. "/dev/dsk/c0t1d2s3" is controller 0 (first SCSI controller seen on
> the bus), target ID 1, LUN 2, partition (slice) 3.  Simple, unambiguous
> and repeatable.
> 
> I understand that other devices may be seen on the PCI if you add or
> remove cards.  Under this scheme, controller 0 is the first (lowest
> slot number) unit found.  The next one would be controller 1.  Even
> if you were to stuff, say, a video card in there, these would _still_
> be the first SCSI cards found.  The only time a change would occur
> is if a SCSI card was installed in a lower slot number or between
> other SCSI controllers (and only then if the original cards were
> left in) or if the ORDER of the cards was changed in the bus.
> 
> As I said, other people smarter than I seem to think it makes sense.
> Why not Linux?  It's silly to smush things together just to satisfy a
> bizzare craving to have a list of devices with no "holes" in it.
> Besides "fsck"ing or "mkfs"ing drives, how often do you refer to them
> by their names in "/dev", anyway?
> 
> This would also work for tape drives.  However, they're rooted at
> /dev/stape rather than /dev/dsk.
> 
> At boot, you could create more mnemonic names as symbolic links to the
> CTL names if you wish (as is done with /dev/cdrom and such), but if
> you absolutely want to talk to the SAME DEVICE, you use the CTL name.
> 
> Just adding my $0.02.  We now return you to your regularly scheduled
> arguments.
> 
> ----------------------------------------------------------------------
> - Rick Stevens, SSE, VitalStream, Inc.      rstevens@vitalstream.com -
> - 949-743-2010 (Voice)                    http://www.vitalstream.com -
> -                                                                    -
> -          su -; find / -name someone -exec touch \{\} \;            -
> -                          - The UNIX way of touching someone        -
> ----------------------------------------------------------------------
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [RFC] Persistent naming of scsi devices

[Linus Torvalds]

In article <3CB39285.8000609@vitalstream.com>,
Rick Stevens  <rstevens@vitalstream.com> wrote:
>
> [ Position-based naming ]
>
>As I said, other people smarter than I seem to think it makes sense.

No, those people were probably not smarter than you. In fact, they are
likely complete morons.

Position means nothing.  Anybody who bases naming on position is just
bending over and waiting for it when it comes to hotplugging etc.  It
solves none of the problems it is claimed to solve (ie the names are
_not_ constant), and it fundamentally locks you into a mindset that
simply isn't true. 

>Why not Linux?  It's silly to smush things together just to satisfy a
>bizzare craving to have a list of devices with no "holes" in it.

No, it's silly to think that you can enumerate the address space: you
can't. The only thing you get from trying is a horrible mess in /dev
that adds zero information anywhere.

You're much better off just enumerating your SCSI devices the trivial
way (ie 0, 1, 2 ....  completely independent on position - each device
gets one unique number that has no inherent meaning and is UNDERSTOOD to
have no inherent meaning, only an ID) and then having a way to query
their attibutes.  That way you can use the attributes (which are _NOT_
identities) to create whatever "convenient mapping" you want. 

The position of a drive is not its name, it's just one random attribute
in a sea of other random attributes.  Depending on what you do, it might
be a useful one, but it's equally likely that it is completely
meaningless.  Trying to make it inherently meaningful is just *wrong*.

		Linus

Re: [RFC] Persistent naming of scsi devices

[Martin K. Petersen]

Rick> E.g. "/dev/dsk/c0t1d2s3" is controller 0 (first SCSI controller
Rick> seen on the bus), target ID 1, LUN 2, partition (slice) 3.
Rick> Simple, unambiguous and repeatable.

You plug in another SCSI controller and then what happens?  Or one of
your existing controllers goes up in blue smoke?

What we want is (at least) three ways of addressing a device:

1. By content.  This is the persistent naming.  Think
   filesystem/MD/LVM UUID.  This is what you put in /etc/fstab and
   what metadisk systems use to assemble logical volumes.

   Content referencing is used for accessing data.

2. By physical path.  This naming is not persistent.  Not even runtime
   because hotplug, iSCSI and whatnot may mess things up.

   Path naming is for discovery and recovery.  When you add an
   unlabeled disk you want to reference it by path to give it a name.
   When you have a failed disk on your system you want to know which
   physical device to pull from the array.

3. By enumeration.  This is what the kernel happens to be using to
   reference the device.  diskN.  Certainly not persistent.

   Enumeration is for the kernel.

Now, some magic needs to be involved at discovery time because we
can't rely only on neither content addressing, nor path addressing
alone to do the right thing.  And why is that?

Well, imagine you have a set of mirrored disks.  If you only address
by content, you will find have two devices that match (or three if MD
has done autodetection).  What you really want to mount is the MD
device.

Multipathing has a similar problem.  You'll see two copies of the same
filesystem/UUID.  And again you really want the metadevice to be
mounted.

So not only is your proposal a bad idea for persistency reasons.  The
scheme does not carry enough information to do what is needed.

-- 
Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc.
mkp@linuxcare.com, http://www.linuxcare.com/
SGI XFS for Linux Developer, http://oss.sgi.com/projects/xfs/

Re: [RFC] Persistent naming of scsi devices

[Theodore Tso]

On Tue, Apr 09, 2002 at 11:37:44PM -0400, Martin K. Petersen wrote:
> Well, imagine you have a set of mirrored disks.  If you only address
> by content, you will find have two devices that match (or three if MD
> has done autodetection).  What you really want to mount is the MD
> device.
> 
> Multipathing has a similar problem.  You'll see two copies of the same
> filesystem/UUID.  And again you really want the metadevice to be
> mounted.

Note that fsck (and I think mount, but I definitely know about fsck
because I maintain it) solves the above problem by searching the MD
devices first.  Once the multipathing becomes stable, again the right
answer for fsck is to search the metadevice first.

Andreas Dilger has written a block-device-id library which is really
promising, and the goal is to abstract out the current search
algorithms currently used by fsck and mount into a single library.
Said library will also cache the location of filesystems by UUID and
label name, and when a particular block device corresponding to
UUID=XXX or LABEL=YYY is requested, it can look up the location in the
cache, validate it to make sure that someone hasn't inserted or
removed a SCSI controller card, and then return the answer.  If the
validation fails, the library will then do a full sweep of all of the
known devices (again, doing the metadevices --- LVM, MD, et. al ---
first, to deal with the problem you listed).

This basically deals with all of the problems except for swap (which
doesn't have a UUID --- but it shouldn't be too hard to add a UUID
into the swap signature, and then teach swapon how to use it), and the
problem of initializing new disks, before they have UUID's attached to
it. 

That is indeed a hard problem, and ultimately, the thing that will
make this easier is if there's some way we can read out a
drive-specific serial number out of the ATAPI or SCSI interfaces.  I
don't know if disk serial numbers are commonly supported by disk
manufacturers, but hopefully the newer disks have something like that
we can use.  Without it, though, the problem is very, very hard if you
want to make it 100% foolproof --- and hence, something which
civilians (i.e., stupid users) can use.

						- Ted

Re: [RFC] Persistent naming of scsi devices

[Eddie Williams]

On Wednesday 10 April 2002 09:19 am, Theodore Tso wrote:

> That is indeed a hard problem, and ultimately, the thing that will
> make this easier is if there's some way we can read out a
> drive-specific serial number out of the ATAPI or SCSI interfaces.  I
> don't know if disk serial numbers are commonly supported by disk
> manufacturers, but hopefully the newer disks have something like that
> we can use.  Without it, though, the problem is very, very hard if you
> want to make it 100% foolproof --- and hence, something which
> civilians (i.e., stupid users) can use.

While I enjoy bashing stupid users I would like to point out that persistent 
naming, while it makes life easier for stupid users, it has tremendous 
benefits for all of us.  

We (the product I work on) have used serial numbers for a long time to 
uniquely identify devices and this improves the ease of use tremendously.  In 
a cluster this is really critical or one can easily try to bring an 
application in-service on a wrong device with catestrophic results.

Eddie

RE: [RFC] Persistent naming of scsi devices

[berthiaume_wayne]

	Actually, it would be easier to control if it uses its actual PCI
slot number, for example c2 for the second slot, as opposed to c2 for the
second SCSI controller. This would be easier to implement and would be
"persistent" as long as the controller is not moved. Doing it in the manner
you suggest would not provide persistence but revert to the order of
discovery we already have with a different naming convention. Doesn't seem
like a wise alternative. The intention of the CTDL nomenclature is to
provide precise device targeting without the BS mapping to some arbitrarily
named device table. In DG/AViiON, more precisely DG/UX, it was CTDL based
but then mapped to a device mneumonic in the devtable. Devices were named in
the system config file by their long name (CTDL) and linked in the devtable
to its short name, for example /dev/pdsk/sd0 for the buffered SCSI disk and
/dev/rpdsk/sd0 for the raw SCSI disk. We used different SCSI controllers but
this didn't present a problem because, they were placed in the kernel config
file. If the Ciprico was in slot 0 and in the kernel's spec file, it's long
name was entered into the devtable and linked at boot to the short name
/dev/pdsk/sd0. Conversely, if the Adaptec was in slot 0 and configured into
the kernel spec file, its long name would be entered into the devtable and
linked to the /dev/pdsk/sd0 short name.
Wayne
EMC Corp
Centera Engineering
4400 Computer Drive
M/S F213
Westboro,  MA    01580

email:       Berthiaume_Wayne@emc.com

"One man can make a difference, and every man should try."  - JFK


-----Original Message-----
From: Rick Stevens [mailto:rstevens@vitalstream.com]
Sent: Tuesday, April 09, 2002 9:17 PM
To: linux-scsi@vger.kernel.org
Subject: Re: [RFC] Persistent naming of scsi devices


Martin Peschke3 wrote:

<much stuff snipped>

I'm going to wade in here.  Based on my experiences on many other
Unixish systems, wouldn't it be simply better to number the things
based on controller position, SCSI ID, LUN and partition?  This
has been called "CTL" format in various documents, and many systems
use this method such as Sun, DG AvIIons, DEC, HP and a host of others.

E.g. "/dev/dsk/c0t1d2s3" is controller 0 (first SCSI controller seen on
the bus), target ID 1, LUN 2, partition (slice) 3.  Simple, unambiguous
and repeatable.

I understand that other devices may be seen on the PCI if you add or
remove cards.  Under this scheme, controller 0 is the first (lowest
slot number) unit found.  The next one would be controller 1.  Even
if you were to stuff, say, a video card in there, these would _still_
be the first SCSI cards found.  The only time a change would occur
is if a SCSI card was installed in a lower slot number or between
other SCSI controllers (and only then if the original cards were
left in) or if the ORDER of the cards was changed in the bus.

As I said, other people smarter than I seem to think it makes sense.
Why not Linux?  It's silly to smush things together just to satisfy a
bizzare craving to have a list of devices with no "holes" in it.
Besides "fsck"ing or "mkfs"ing drives, how often do you refer to them
by their names in "/dev", anyway?

This would also work for tape drives.  However, they're rooted at
/dev/stape rather than /dev/dsk.

At boot, you could create more mnemonic names as symbolic links to the
CTL names if you wish (as is done with /dev/cdrom and such), but if
you absolutely want to talk to the SAME DEVICE, you use the CTL name.

Just adding my $0.02.  We now return you to your regularly scheduled
arguments.

----------------------------------------------------------------------
- Rick Stevens, SSE, VitalStream, Inc.      rstevens@vitalstream.com -
- 949-743-2010 (Voice)                    http://www.vitalstream.com -
-                                                                    -
-          su -; find / -name someone -exec touch \{\} \;            -
-                          - The UNIX way of touching someone        -
----------------------------------------------------------------------

-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [RFC] Persistent naming of scsi devices

[berthiaume_wayne]

	This is true with the design of today's virtual LUNs on the storage
arrays. However, I believe that if you are sharing a VLUN on the array the
same WWNN/WWPN is assigned to it. Though it may be represented to you as
VLUN 1 in your virtual storage system and VLUN 6 in mine I thought the same
WWNN/WWPN was assigned to it.

-----Original Message-----
From: Bryan Henderson [mailto:hbryan@us.ibm.com]
Sent: Tuesday, April 09, 2002 9:40 PM
To: Rick Stevens
Cc: linux-scsi@vger.kernel.org
Subject: Re: [RFC] Persistent naming of scsi devices


>E.g. "/dev/dsk/c0t1d2s3" is controller 0 (first SCSI controller seen on
>the bus), target ID 1, LUN 2, partition (slice) 3.  Simple, unambiguous
>and repeatable.

For many purposes, you're right, and for that reason devfs already does 
this.  However, in some cases these are not repeatable.  A volume that is 
LUN 5 today could be LUN 7 tomorrow.  This is true in heavy-duty disk 
storage subsystems that let you create and destroy logical units on the 
fly, using the physical medium as a resource pool.  And what is LUN 5 for 
me could be LUN 7 for you at the same time, if we're both wired into the 
same storage subsystem.

-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [RFC] Persistent naming of scsi devices

[Bryan Henderson]

>I believe that if you are sharing a VLUN on the array the
>same WWNN/WWPN is assigned to it. Though it may be represented to you as
>VLUN 1 in your virtual storage system and VLUN 6 in mine I thought the
same
>WWNN/WWPN was assigned to it.

Yes, every system I've seen does that and it seems to be the intent (for
whatever that's worth) of the fibre channel architects.  But how is that
relevant?  We're talking about uniquely identifying a logical unit (which
is what would appear in Linux as a device).

I don't know what a VLUN is, so maybe I'm just lost.  Isn't that redundant?
Virtual and logical are the same thing.

Leave the WWPN (worldwide port number) out of it, by the way.  That doesn't
help identify devices, just ports that can be used to reach them.

Re: [RFC] Persistent naming of scsi devices

[Martin Peschke3]

Matt,

> > > It's more than just a WWN- it really has to be
> > > the pair of WWNN/WWPN (node && port name) as you
> > > can have, e.g., a dual ported disk with the same WWNN but
> > > different WWPNs.
> >
> > Ok, I thought of WWPN and that it would be sufficient to identify the
> > target side of a link, isn't it? Do you really need a pair of
WWNN/WWPN,
> > i.e. identical WWPNs might exist considering different WWNNs?
>
> If the numbering is NAA=2 (2 in the top nibble), you can always derive
the
> WWNN from the WWPN. But that's only true for NAA=2.
>
> In *practice*, WWPN might be enough,  but if we're doing things that
formally
> and fully ID a device, and considering that iSCSI identifiers are 255
bytes or
> better, two 64 bit ids for Fibre Channel devices is not unreasonable to
allow
> for.
>
> -matt

If there are cases which require WWNN+WWPN to identify a
FC port then a you would need this pair to query a FC ports
D_ID. I wonder why this is not reflected in the FC name server
specification, FC-GS-3, (see GID_PN for example).


Mit freundlichen Grüßen / with kind regards

Martin Peschke

IBM Deutschland Entwicklung GmbH
Linux for eServer Development
Phone: +49-(0)7031-16-2349


-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [RFC] Persistent naming of scsi devices

[Matthew Jacob]

That's why you always trail lun off of the wwnn/wwpn- see solaris' ssd device
names.


On Wed, 10 Apr 2002 berthiaume_wayne@emc.com wrote:

> 	This is true with the design of today's virtual LUNs on the storage
> arrays. However, I believe that if you are sharing a VLUN on the array the
> same WWNN/WWPN is assigned to it. Though it may be represented to you as
> VLUN 1 in your virtual storage system and VLUN 6 in mine I thought the same
> WWNN/WWPN was assigned to it.
> 
> -----Original Message-----
> From: Bryan Henderson [mailto:hbryan@us.ibm.com]
> Sent: Tuesday, April 09, 2002 9:40 PM
> To: Rick Stevens
> Cc: linux-scsi@vger.kernel.org
> Subject: Re: [RFC] Persistent naming of scsi devices
> 
> 
> >E.g. "/dev/dsk/c0t1d2s3" is controller 0 (first SCSI controller seen on
> >the bus), target ID 1, LUN 2, partition (slice) 3.  Simple, unambiguous
> >and repeatable.
> 
> For many purposes, you're right, and for that reason devfs already does 
> this.  However, in some cases these are not repeatable.  A volume that is 
> LUN 5 today could be LUN 7 tomorrow.  This is true in heavy-duty disk 
> storage subsystems that let you create and destroy logical units on the 
> fly, using the physical medium as a resource pool.  And what is LUN 5 for 
> me could be LUN 7 for you at the same time, if we're both wired into the 
> same storage subsystem.
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

RE: [RFC] Persistent naming of scsi devices

[berthiaume_wayne]

	VLUN = virtual LUN   

	This would be the number assigned by the storage system. A storage
system can be broken up into multiple virtual storage systems each unique to
the owner. The real trick is when to virtual storage systems share the same
LUN. Depending on the order of entry into the virtual storage array on a
CLARiiON at the time it is being configured it could be a LUN 1 to your
virtual storage and LUN 6 on mine.

-----Original Message-----
From: Bryan Henderson [mailto:hbryan@us.ibm.com]
Sent: Wednesday, April 10, 2002 11:28 AM
To: berthiaume_wayne@emc.com
Cc: linux-scsi@vger.kernel.org
Subject: RE: [RFC] Persistent naming of scsi devices



>I believe that if you are sharing a VLUN on the array the
>same WWNN/WWPN is assigned to it. Though it may be represented to you as
>VLUN 1 in your virtual storage system and VLUN 6 in mine I thought the
same
>WWNN/WWPN was assigned to it.

Yes, every system I've seen does that and it seems to be the intent (for
whatever that's worth) of the fibre channel architects.  But how is that
relevant?  We're talking about uniquely identifying a logical unit (which
is what would appear in Linux as a device).

I don't know what a VLUN is, so maybe I'm just lost.  Isn't that redundant?
Virtual and logical are the same thing.

Leave the WWPN (worldwide port number) out of it, by the way.  That doesn't
help identify devices, just ports that can be used to reach them.

Re: [RFC] Persistent naming of scsi devices

[Mike Anderson]

Eddie Williams [Eddie.Williams@steeleye.com] wrote:
> On Wednesday 10 April 2002 09:19 am, Theodore Tso wrote:
> 
> > That is indeed a hard problem, and ultimately, the thing that will
> > make this easier is if there's some way we can read out a
> > drive-specific serial number out of the ATAPI or SCSI interfaces.  I
> > don't know if disk serial numbers are commonly supported by disk
> > manufacturers, but hopefully the newer disks have something like that
> > we can use.  Without it, though, the problem is very, very hard if you
> > want to make it 100% foolproof --- and hence, something which
> > civilians (i.e., stupid users) can use.
> 
> While I enjoy bashing stupid users I would like to point out that persistent 
> naming, while it makes life easier for stupid users, it has tremendous 
> benefits for all of us.  
> 
> We (the product I work on) have used serial numbers for a long time to 
> uniquely identify devices and this improves the ease of use tremendously.  In 
> a cluster this is really critical or one can easily try to bring an 
> application in-service on a wrong device with catestrophic results.

Agreed,

While the immutablity / uniqueness of uuids across different name spaces
may vary depending on device capability there are still useful. Many have
been obtaining IDs from devices for years using a method of obtaining the
most unique ID the device can provide and then ensuring that names spaces
do not collide (i.e go for page 0x83, then 0x80, vendor-product-serial,
vendor unique).

We have also found in the past that when users make complete copies of
there volumes (for the purpose of hot-backup) that a uuid is one of the
few methods that can be used to differ the clone from the original.


-Mike
-- 
Michael Anderson
andmike@us.ibm.com

RE: [RFC] Persistent naming of scsi devices

[Martin Peschke3]

What's about non-PCI SCSI adapters?

Another idea regarding a topology oriented naming scheme:

replace     /dev/scsi/host<index>/...
by          /dev/scsi/<hba driver name>/<unique id>/...

Both <hba driver name> and <unique id> are available for each
HBA in the mid layers data today.
This proposal assumes that a particular HBA is driven by
not more than one HBA driver at the same time. Besides,
<unique id> (provided by HBA driver) should be persistent
in the scope of a particular HBA driver. You might use PCI
slot or any other architecture dependent characteristic.


Mit freundlichen Grüßen / with kind regards

Martin Peschke

IBM Deutschland Entwicklung GmbH
Linux for eServer Development
Phone: +49-(0)7031-16-2349


berthiaume_wayne@emc.com@vger.kernel.org on 04/10/2002 04:28:33 PM

Please respond to berthiaume_wayne@emc.com

Sent by:    linux-scsi-owner@vger.kernel.org


To:    rstevens@vitalstream.com
cc:    linux-scsi@vger.kernel.org
Subject:    RE: [RFC] Persistent naming of scsi devices



 Actually, it would be easier to control if it uses its actual PCI
slot number, for example c2 for the second slot, as opposed to c2 for the
second SCSI controller. This would be easier to implement and would be
"persistent" as long as the controller is not moved. Doing it in the manner
you suggest would not provide persistence but revert to the order of
discovery we already have with a different naming convention. Doesn't seem
like a wise alternative. The intention of the CTDL nomenclature is to
provide precise device targeting without the BS mapping to some arbitrarily
named device table. In DG/AViiON, more precisely DG/UX, it was CTDL based
but then mapped to a device mneumonic in the devtable. Devices were named
in
the system config file by their long name (CTDL) and linked in the devtable
to its short name, for example /dev/pdsk/sd0 for the buffered SCSI disk and
/dev/rpdsk/sd0 for the raw SCSI disk. We used different SCSI controllers
but
this didn't present a problem because, they were placed in the kernel
config
file. If the Ciprico was in slot 0 and in the kernel's spec file, it's long
name was entered into the devtable and linked at boot to the short name
/dev/pdsk/sd0. Conversely, if the Adaptec was in slot 0 and configured into
the kernel spec file, its long name would be entered into the devtable and
linked to the /dev/pdsk/sd0 short name.
Wayne
EMC Corp
Centera Engineering
4400 Computer Drive
M/S F213
Westboro,  MA    01580

email:       Berthiaume_Wayne@emc.com

"One man can make a difference, and every man should try."  - JFK


-----Original Message-----
From: Rick Stevens [mailto:rstevens@vitalstream.com]
Sent: Tuesday, April 09, 2002 9:17 PM
To: linux-scsi@vger.kernel.org
Subject: Re: [RFC] Persistent naming of scsi devices


Martin Peschke3 wrote:

<much stuff snipped>

I'm going to wade in here.  Based on my experiences on many other
Unixish systems, wouldn't it be simply better to number the things
based on controller position, SCSI ID, LUN and partition?  This
has been called "CTL" format in various documents, and many systems
use this method such as Sun, DG AvIIons, DEC, HP and a host of others.

E.g. "/dev/dsk/c0t1d2s3" is controller 0 (first SCSI controller seen on
the bus), target ID 1, LUN 2, partition (slice) 3.  Simple, unambiguous
and repeatable.

I understand that other devices may be seen on the PCI if you add or
remove cards.  Under this scheme, controller 0 is the first (lowest
slot number) unit found.  The next one would be controller 1.  Even
if you were to stuff, say, a video card in there, these would _still_
be the first SCSI cards found.  The only time a change would occur
is if a SCSI card was installed in a lower slot number or between
other SCSI controllers (and only then if the original cards were
left in) or if the ORDER of the cards was changed in the bus.

As I said, other people smarter than I seem to think it makes sense.
Why not Linux?  It's silly to smush things together just to satisfy a
bizzare craving to have a list of devices with no "holes" in it.
Besides "fsck"ing or "mkfs"ing drives, how often do you refer to them
by their names in "/dev", anyway?

This would also work for tape drives.  However, they're rooted at
/dev/stape rather than /dev/dsk.

At boot, you could create more mnemonic names as symbolic links to the
CTL names if you wish (as is done with /dev/cdrom and such), but if
you absolutely want to talk to the SAME DEVICE, you use the CTL name.

Just adding my $0.02.  We now return you to your regularly scheduled
arguments.

----------------------------------------------------------------------
- Rick Stevens, SSE, VitalStream, Inc.      rstevens@vitalstream.com -
- 949-743-2010 (Voice)                    http://www.vitalstream.com -
-                                                                    -
-          su -; find / -name someone -exec touch \{\} \;            -
-                          - The UNIX way of touching someone        -
----------------------------------------------------------------------

-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html



-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] Persistent naming of scsi devices

[Matthew Jacob]

> If there are cases which require WWNN+WWPN to identify a FC port then a
> you would need this pair to query a FC ports D_ID. I wonder why this is
> not reflected in the FC name server specification, FC-GS-3, (see GID_PN
> for example).

Good question.

But I believe that in sending a CT frame to the name server with PortID XXXXXX
to ask it what the Port Name is or the Node Name, all you're doing is to ask
it to use that PortID as a search key and return the Port Name. This hasn't
got all that much to do with initiators needing to use WWNN+WWPN (currently
bound with D_ID such and such) to uniquely, and persistently, identify a
device.

I mean, to use FC-GS-2 or FC-GS-3, you do something like

GID_FT
(gimme a list of Port IDs on the fabric for the FC4 type I want to know about)

For each member of the returned list do:

	GPN_ID (get it's port name)

	GNN_ID (get it's node name)

	optionally: GFF_ID (get it's FC4 features. For FC-SCSI this gets
	you Initiator/Target support roles)

You would think that there would be one CT command to return *both* Port and
Node names- and there is (it's part of the return data at least for GA_NXT).

It's my ill informed opinion that this design is a result of a difference of
opinion about the usages of WWPN/WWNN within the t10 committee. I believe I've
heard one of the members expresss regret over having separate numbers.


Be that as it may be, we *know* we have cases where you *must* use both the
WWNN and WWPN to *uniquely* ID the device. If I have just about any FC disk
drive, it is going to have a common WWNN but different WWPNs depending on
whether you talk to it via FC_AL Port A or Port B connections. If I have the
drive in a JMR JBOD with both Port A and Port B connectors, and connect both
to HBAs from a system (e.g., to provide warm failover), I really need *both*
WWPN and WWNN to keep track of which drive is which drive.

I *might* want to treat them as the same (e.g., for transparent failover), but
this should be under control, not happenstance depending on whether I decide
to use just one of WWNN or WWPN to ID devices.

-matt

RE: [RFC] Persistent naming of scsi devices

[berthiaume_wayne]

	True, there is a hole in the PCI slot logic - onboard SCSI chips for
instance. Using /dev/scsi/<hba driver name>/<unique id>/... does have it
merits as it would lend a quick physical identification, if one can remember
the driver's name for a particular HBA. =;^)

-----Original Message-----
From: Martin Peschke3 [mailto:MPESCHKE@de.ibm.com]
Sent: Wednesday, April 10, 2002 3:03 PM
To: berthiaume_wayne@emc.com
Cc: rstevens@vitalstream.com; linux-scsi@vger.kernel.org
Subject: RE: [RFC] Persistent naming of scsi devices



What's about non-PCI SCSI adapters?

Another idea regarding a topology oriented naming scheme:

replace     /dev/scsi/host<index>/...
by          /dev/scsi/<hba driver name>/<unique id>/...

Both <hba driver name> and <unique id> are available for each
HBA in the mid layers data today.
This proposal assumes that a particular HBA is driven by
not more than one HBA driver at the same time. Besides,
<unique id> (provided by HBA driver) should be persistent
in the scope of a particular HBA driver. You might use PCI
slot or any other architecture dependent characteristic.


Mit freundlichen Grüßen / with kind regards

Martin Peschke

IBM Deutschland Entwicklung GmbH
Linux for eServer Development
Phone: +49-(0)7031-16-2349


berthiaume_wayne@emc.com@vger.kernel.org on 04/10/2002 04:28:33 PM

Please respond to berthiaume_wayne@emc.com

Sent by:    linux-scsi-owner@vger.kernel.org


To:    rstevens@vitalstream.com
cc:    linux-scsi@vger.kernel.org
Subject:    RE: [RFC] Persistent naming of scsi devices



 Actually, it would be easier to control if it uses its actual PCI
slot number, for example c2 for the second slot, as opposed to c2 for the
second SCSI controller. This would be easier to implement and would be
"persistent" as long as the controller is not moved. Doing it in the manner
you suggest would not provide persistence but revert to the order of
discovery we already have with a different naming convention. Doesn't seem
like a wise alternative. The intention of the CTDL nomenclature is to
provide precise device targeting without the BS mapping to some arbitrarily
named device table. In DG/AViiON, more precisely DG/UX, it was CTDL based
but then mapped to a device mneumonic in the devtable. Devices were named
in
the system config file by their long name (CTDL) and linked in the devtable
to its short name, for example /dev/pdsk/sd0 for the buffered SCSI disk and
/dev/rpdsk/sd0 for the raw SCSI disk. We used different SCSI controllers
but
this didn't present a problem because, they were placed in the kernel
config
file. If the Ciprico was in slot 0 and in the kernel's spec file, it's long
name was entered into the devtable and linked at boot to the short name
/dev/pdsk/sd0. Conversely, if the Adaptec was in slot 0 and configured into
the kernel spec file, its long name would be entered into the devtable and
linked to the /dev/pdsk/sd0 short name.
Wayne
EMC Corp
Centera Engineering
4400 Computer Drive
M/S F213
Westboro,  MA    01580

email:       Berthiaume_Wayne@emc.com

"One man can make a difference, and every man should try."  - JFK


-----Original Message-----
From: Rick Stevens [mailto:rstevens@vitalstream.com]
Sent: Tuesday, April 09, 2002 9:17 PM
To: linux-scsi@vger.kernel.org
Subject: Re: [RFC] Persistent naming of scsi devices


Martin Peschke3 wrote:

<much stuff snipped>

I'm going to wade in here.  Based on my experiences on many other
Unixish systems, wouldn't it be simply better to number the things
based on controller position, SCSI ID, LUN and partition?  This
has been called "CTL" format in various documents, and many systems
use this method such as Sun, DG AvIIons, DEC, HP and a host of others.

E.g. "/dev/dsk/c0t1d2s3" is controller 0 (first SCSI controller seen on
the bus), target ID 1, LUN 2, partition (slice) 3.  Simple, unambiguous
and repeatable.

I understand that other devices may be seen on the PCI if you add or
remove cards.  Under this scheme, controller 0 is the first (lowest
slot number) unit found.  The next one would be controller 1.  Even
if you were to stuff, say, a video card in there, these would _still_
be the first SCSI cards found.  The only time a change would occur
is if a SCSI card was installed in a lower slot number or between
other SCSI controllers (and only then if the original cards were
left in) or if the ORDER of the cards was changed in the bus.

As I said, other people smarter than I seem to think it makes sense.
Why not Linux?  It's silly to smush things together just to satisfy a
bizzare craving to have a list of devices with no "holes" in it.
Besides "fsck"ing or "mkfs"ing drives, how often do you refer to them
by their names in "/dev", anyway?

This would also work for tape drives.  However, they're rooted at
/dev/stape rather than /dev/dsk.

At boot, you could create more mnemonic names as symbolic links to the
CTL names if you wish (as is done with /dev/cdrom and such), but if
you absolutely want to talk to the SAME DEVICE, you use the CTL name.

Just adding my $0.02.  We now return you to your regularly scheduled
arguments.

----------------------------------------------------------------------
- Rick Stevens, SSE, VitalStream, Inc.      rstevens@vitalstream.com -
- 949-743-2010 (Voice)                    http://www.vitalstream.com -
-                                                                    -
-          su -; find / -name someone -exec touch \{\} \;            -
-                          - The UNIX way of touching someone        -
----------------------------------------------------------------------

-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [RFC] Persistent naming of scsi devices

[Bryan Henderson]

>                VLUN = virtual LUN 
>
>This would be the number assigned by the storage system. A storage
>system can be broken up into multiple virtual storage systems each unique 
to
>the owner. The real trick is when to virtual storage systems share the 
same
>LUN.

This VLUN sounds like what SCSI/FCP defines as a LUN.  What you're calling 
a LUN is apparently something that's not defined in SCSI.  I'm guessing a 
LUN here identifies a volume, and the same volume is connected to multiple 
SCSI logical units, one in each virtual storage subsystem.  I'm also 
assuming that a virtual storage subsystem is a target device/node in SCSI 
terms.

That raises the question:  What do you get if you INQUIRE as to the 
logical unit serial number of two SCSI logical units, in different virtual 
storage subsystems, associated with the same volume?  Is it the same 
serial number?

RE: [RFC] Persistent naming of scsi devices

[berthiaume_wayne]

	The CLARiiON returns pages 00h, 80h, and 83h. Page 80h will contain
the array's serial number. Bytes 4 thru 23 of page 83h contain the
Identifier Descriptor 0 data which carries the LUN's WWN and bytes 24 thru
43 contain the Identifier Descriptor 1 data which carries the LUN and VLU
numbers. The LUN/VLU come from the VLUT (Virtual LUN Table). This is how you
are able to map your virtual LUN in your storage group to the physical LUN
in the array. The physical LUN itself is not a physical disk in the physical
array but created at the time you bind disks or portions of disks into LUN.
For example, I may bind five disks into a RAID 5 group and portion them up
into 10 LUNs. Then if I install and use the AccessLogix software on the
array I can break up the array into virtual arrays called Storage Groups to
be used by multiple hosts. Storage Groups can be shared or individually
owned and, for the clever array administrator, you can design individual
storage groups which contain private and shared LUNs. All this is only
possible because we utilize the WWN of the array. The LUNs themselves use a
concatenation of the array's WWN to form the WWN for each individual LUN.
The WWN for the attached HBA is used to identify the unique storage group.
Thus persistence is maintained in the array. Now the trick will be to get
the same for Linux. =;^)

-----Original Message-----
From: Bryan Henderson [mailto:hbryan@us.ibm.com]
Sent: Thursday, April 11, 2002 12:01 PM
To: berthiaume_wayne@emc.com
Cc: linux-scsi@vger.kernel.org
Subject: RE: [RFC] Persistent naming of scsi devices


>                VLUN = virtual LUN 
>
>This would be the number assigned by the storage system. A storage
>system can be broken up into multiple virtual storage systems each unique 
to
>the owner. The real trick is when to virtual storage systems share the 
same
>LUN.

This VLUN sounds like what SCSI/FCP defines as a LUN.  What you're calling 
a LUN is apparently something that's not defined in SCSI.  I'm guessing a 
LUN here identifies a volume, and the same volume is connected to multiple 
SCSI logical units, one in each virtual storage subsystem.  I'm also 
assuming that a virtual storage subsystem is a target device/node in SCSI 
terms.

That raises the question:  What do you get if you INQUIRE as to the 
logical unit serial number of two SCSI logical units, in different virtual 
storage subsystems, associated with the same volume?  Is it the same 
serial number?

RE: [RFC] Persistent naming of scsi devices

[Bryan Henderson]

That clarifies things a bit.  Clariion uses an unfortunate terminology; we
have to keep that in mind in these naming discussions because, for example,
when we talk a about making a device file name out of host/bus/target/lun,
we're talking about a Clariion VLUN, not a Clariion LUN.  The Clariion LUN
is what I believe most others would call a "volume."  Or maybe a virtual
disk.

>The physical LUN itself is not a physical disk in the physical
>array but created at the time you bind disks or portions of disks into
LUN.

Don't you feel funny saying "physical LUN" (physical logical unit number)?
:-) Is it physical or logical?  And is it a number or a storage medium?

RE: [RFC] Persistent naming of scsi devices

[berthiaume_wayne]

	I guess I hail back from when a LUN, or as I ahd always perceived
it, was a whole device and not a portion of one or several (if they were
bound in a RAID group.) =%^)

-----Original Message-----
From: Bryan Henderson [mailto:hbryan@us.ibm.com]
Sent: Friday, April 12, 2002 1:19 PM
To: berthiaume_wayne@emc.com
Cc: linux-scsi@vger.kernel.org
Subject: RE: [RFC] Persistent naming of scsi devices



That clarifies things a bit.  Clariion uses an unfortunate terminology; we
have to keep that in mind in these naming discussions because, for example,
when we talk a about making a device file name out of host/bus/target/lun,
we're talking about a Clariion VLUN, not a Clariion LUN.  The Clariion LUN
is what I believe most others would call a "volume."  Or maybe a virtual
disk.

>The physical LUN itself is not a physical disk in the physical
>array but created at the time you bind disks or portions of disks into
LUN.

Don't you feel funny saying "physical LUN" (physical logical unit number)?
:-) Is it physical or logical?  And is it a number or a storage medium?


-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC] Persistent naming of scsi devices

[sullivan]

Thanks for your postings to the original RFC submitted under this subject. Based on your feedback two utilities are now available at http://oss.software.ibm.com/devreg/
a. scsiname utility
	- Makes sg calls to collect device info used to make naming decisions
	- Hooked into the hotplug interface using Doug Gilbert's scsimon patch
	- Targeted specifically to scsi devices
	- Implemented completely in userspace

b. devnaming utility
	- Utilizes Patrick Mochel's driverfs fs to collect device info
	- Can easily be extended to support other device types (non scsi)
	- Includes a kernel patch to create/publish device info in driverfs
	- Hooked into hotplug interface using scsimon patch

Why two utilities? I see scsiname providing an immediate fix for providing a persistent set of /dev scsi names across boots. The devnaming utility is more long term in that it anticipates that driverfs will evolve into providing the device information necessary, removing the need for interfacing through sg. The config and hotplug portions of the utilities are consistent and should (hopefully) provide a smooth migration path.

I'd appreciate feedback from anyone that has the interest and the time to take a further look.

Re: [RFC] Persistent naming of scsi devices

[Douglas Gilbert]

sullivan wrote:
> 
> Thanks for your postings to the original RFC submitted under this subject. Based on your feedback two utilities are now available at http://oss.software.ibm.com/devreg/
> a. scsiname utility
>         - Makes sg calls to collect device info used to make naming decisions
>         - Hooked into the hotplug interface using Doug Gilbert's scsimon patch
>         - Targeted specifically to scsi devices
>         - Implemented completely in userspace
> 
> b. devnaming utility
>         - Utilizes Patrick Mochel's driverfs fs to collect device info
>         - Can easily be extended to support other device types (non scsi)
>         - Includes a kernel patch to create/publish device info in driverfs
>         - Hooked into hotplug interface using scsimon patch
> 
> Why two utilities? I see scsiname providing an immediate fix for 
> providing a persistent set of /dev scsi names across boots. The 
> devnaming utility is more long term in that it anticipates that 
> driverfs will evolve into providing the device information 
> necessary, removing the need for interfacing through sg. The config
> and hotplug portions of the utilities are consistent and should 
> (hopefully) provide a smooth migration path.
> 
> I'd appreciate feedback from anyone that has the interest and the 
> time to take a further look.

Mike,
Looks good.

I have just updated http://www.torque.net/scsi/scsimon.html
with a version of scsimon for lk 2.5.20 . The patch is
only supeficially different from the previous one (which still
applies with minor noise in drivers/scsi/Makefile ).

Your devnaming patch contains a kernel patch against lk 2.5.14 .
I noticed that driverfs changed in lk 2.5.20 and Patrick Moche
is proposing lots more changes soon (see lkml). Tracking it should
be "interesting". The PCI, USB and IDE subsystem currently have
slots for driverfs, although the PCI one seems to be the only one
active. Getting your driverfs changes for the scsi subsystem into 
Linus's tree may coerce Patrick into keeping the interface up to
date ...

The hotplug facilities that you are using in scsimon are probably
good candidates to go into the scsi mid level in lk 2.5 .

Doug Gilbert