Re: SCSI device rescan, detection of disconnected device, or switched devices.

[Gal Rosen <galr@storwize.com>]

Hi,

I will try to make my question more clear.
I would like to put a box between the client and the storage, and to be
fully transparent against the host. All changes on the storage
(add/remove/extend devices) should be present automatically to the
client. In a direct connection between client and storage the
administrator will coordinate between the client and storage before
making any changes, in my configuration I do not want to add
administration work on my box that stands between the client and the
storage.
Addition is simple, the application on my box can once in a while scan
the SCSI BUS, and then the Linux system will create new sg devices.
In removal of a device the Linux system will not remove sg devices after
scan. In that case again I can do it from my application, such when I
get attention on SCSI command, I can decide to remove the device by
echoing to the /sys file system.

What do you think ? is this enough or there is better way ?

Thanks,
Gal.

On Mon, 2008-07-28 at 15:10 +0200, Stefan Richter wrote:
> 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...).
--
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