On Tue, Aug 23, 2005 at 12:16:45PM -0400, James.Smart@xxxxxxxxxx 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 - : 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
