Gal Rosen wrote: > I know that when adding new device there is no problem; > by echo "- - -" >/sys/class/scsi_host/hostX/scan the SCSI subsystem will > recognize the new device and new /dev/sgX device will be created, but if > someone remove a device, scan will only recognize that the report luns > has changed, but it will not remove the /dev/sgX device. > If now someone add new device it will mapped to the /dev/sgX that > previously mapped to the device that just removed. > > 1. Why the SCSI subsystem doesn't release devices that removed ? Because somewhere someone still holds a reference on the device (for a good reason, or due to a bug). > 2. In the situation that I described above someone can switched devices > without notifying the application that use those devices. The > notification will come only when the next SCSI command will return with > unit attention saying "Power on, reset, or bus device reset occured", or > if device just removed without adding new device it will return > "Reported luns data has changed". > If I have an application that control SCSI devices using sg driver and I > would like to have the ability to change configuration online, what is > the preferred way to rescan the bus and update the application that sgX > that previously controls device Y is now controlling device Z ? > In other words, what is the best way for the application to identify > that device has been removed or changed ? Hmm, I too am curious what the answer to this would be. > 3. I am using Qlogic firmware ability to create virtual ports, and I > notice that on disconnect and then reconnect the FC cable, the sg > mapping can changed. If on module load the physical port got sg0, and on > creating vport it got sg1, now the SCSI subsystem scans the vport first > and mapped it to sg0 and the physical port gets sg1. > Is there a way to control the mapping (scanning) ? There is currently one canonical way: The low-level userspace (udev, hal, or even your application) looks at the device representation in sysfs and fetches persistent and unique properties of the target and logical unit from there. The target identifier and logical unit identifier come first to mind as suitable properties. Then the low-level userspace can for example create symlinks. Most distributions contain udev scripts which do this for sd devices; see /dev/disk/by-id/. Alas there is no standard place where to look for target identifier and logical unit identifier. At least at the last time when I looked for them, the paths to respective sysfs attributes are so far implementation details of the various transport-layer drivers or so-called transport classes (FC, SAS, iSCSI, SBP-2...). -- Stefan Richter -=====-==--- -=== ===-- http://arcgraph.de/sr/ -- 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
