public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: Gal Rosen <galr@storwize.com>
To: Stefan Richter <stefanr@s5r6.in-berlin.de>
Cc: linux-scsi@vger.kernel.org
Subject: Re: SCSI device rescan, detection of disconnected device, or	switched devices.
Date: Thu, 31 Jul 2008 14:48:15 +0300	[thread overview]
Message-ID: <1217504895.25491.69.camel@galr-linux> (raw)
In-Reply-To: <4891792C.6020304@s5r6.in-berlin.de>

On Thu, 2008-07-31 at 10:34 +0200, Stefan Richter wrote:
> Gal Rosen wrote:
> > 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.
> 
> I really don't know how the FibreChannel drivers handle device removal.
> But from what I gather from the documentation of
> fc_remote_port_delete(), which the qla2xxx drivers use, the /dev/sg
> devices should automatically disappear
>   - after a connection loss timeout,
>   - provided that userspace doesn't have the device file opened
>     (among else this is manifest in the kernel in a reference count of
>     the logical unit device representation),
>   - provided that you manage your device files with udev.
> 
> http://lxr.linux.no/linux+v2.6.26/drivers/scsi/scsi_transport_fc.c#L2756
> 

This is true; when the remote port is no longer exists, after timeout
all the sg devices will disappear, but what if I am changing the
configuration in the disk array, and remove only one logical device.
There will not be any event for that. The hotplug implementation in the
SCSI today creates events of add/remove when adding/removing HBA, or
when the FC link go down and up again, but not for additional and
removal of devices. In the linux documentation in scsi_mid_low_api.txt
it is written that "The hotplug concept may be extended to SCSI
devices". I guess that nobody implemented it because what you said
previously in this thread that someone could hold reference to the
device.
I think that I understand the concept. When the FC port is going down/up
you get interrupt, so you can remove all devices or initiate scsi scan
and add devices. But when device is added you can't get any event,
because this device is not known to the client yet (no body is working
with it), all you can do is to initiate scan every once a while. For
removing a device there is a possibility to do it automatically. The LLD
can identify that the device is not ready, and then call to the mid
layer to remove this device. It will succeed only if nobody is holding a
reference to that device.

Gal.
 
> That would be basically just like SCSI device files are created and
> destroyed on the fly for USB or FireWire devices for example.  Except
> that FC has the additional configurable connection loss timeout which
> hides temporary connection losses from applications.
> 
> (However, better wait for an answer of somebody who actually uses FC or
> knows the drivers.  I only have experience with FireWire.)

  reply	other threads:[~2008-07-31 11:48 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-28 12:32 SCSI device rescan, detection of disconnected device, or switched devices Gal Rosen
2008-07-28 13:10 ` Stefan Richter
2008-07-31  6:57   ` Gal Rosen
2008-07-31  8:34     ` Stefan Richter
2008-07-31 11:48       ` Gal Rosen [this message]
2008-07-31 14:15         ` James Bottomley
2008-07-31 15:59           ` Vladislav Bolkhovitin
2008-07-31 16:18             ` James Bottomley
2008-07-31 17:54               ` Vladislav Bolkhovitin
2008-07-31 16:09           ` Gal Rosen
2008-07-31 16:20             ` James Bottomley
     [not found]               ` <0C22B6EFEE0DBB4A9F9F3801E8790B3A732C0C@swdc2.storwiz.com>
2008-08-01 14:29                 ` SCSI device rescan, detection of disconnected device,or " James Bottomley
2008-07-31 17:51         ` James.Smart
2008-07-31 17:46       ` SCSI device rescan, detection of disconnected device, or " James.Smart

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1217504895.25491.69.camel@galr-linux \
    --to=galr@storwize.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=stefanr@s5r6.in-berlin.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox