Re: [PATCH] minimal SAS transport class

[Patrick Mansfield <patmans@us.ibm.com>]

On Tue, Aug 23, 2005 at 12:16:45PM -0400, James.Smart@Emulex.Com wrote:
> > As others stated, id is already a tag/label. You should be 
> > able to pass
> > whatever id you want to scsi_scan_target, like the FC ID 
> > (port_id), and
> > then we also want an abstract iterator in fc transport for the id for
> > usage in scsi_scan.c:scsi_scan_channel. Then you can lose all the
> > fc_host->next_target_id code.
> 
> All nice and well, but....
> 
> How did this help things ?  The issue was the device with a changing
> target id. If the device comes back at the same address each and
> every time, ok. But, with FC, the Port ID is temporal. It can change
> on a loop init, fabric reconfig, or with a user cable swap (kicked
> the cable and replugged).
> 
> If the port id changes during run time, what are you to do ? What if
> a new port is seen at the old port id, how do you now deal with the
> name conflict ? You know apps are going to key off the physical bus
> address being the target - if it changes, this becomes very problematic.

I thought by "the target id is logical for everything but SPI" you meant
that FC enumerated the scsi_device id.

I didn't mean to address problems with persistent names, just map the
scsi_device id to an FC value. We can't keep all the values in the h:c:i:l
constant.

udev (currently, and per Hannes' email in sles9) creates /dev entries with
persistent id's. That does not help if you change scsi_device id values,
or (effectively) remove and add back the same scsi_device. dm-mp should
(eventually?) support that scenario - multipath is really 0 or more paths ...

-- Patrick Mansfield