SCSI reserve / release support for SG

SCSI reserve / release support for SG

[Sachin Sant]

Does Current sg driver offer SCSI reserve/release command in its 
open/close function. I am trying to run on a SAN or Cluster environment
which requires support for this reserve/release command. 

If not then are there any plans to support reserve/release SCSI command
so that sg driver can provide these options for its users in its
open/close function  It will make all I/O operation with sg driver more
reliable especially in data storage area. 

-- 
Thanks
-Sachin
-----------------------------------
Sachin Sant
Linux Technology Center
IBM Software Lab
Bangalore, INDIA.

sachinp@in.ibm.com
Ph: 91-80-5044647
-----------------------------------

Re: SCSI reserve / release support for SG

[Douglas Gilbert]

Sachin Sant wrote:
> Does Current sg driver offer SCSI reserve/release command in its 
> open/close function. 

No.

> I am trying to run on a SAN or Cluster environment
> which requires support for this reserve/release command.

BTW www.t10.org traffic suggests more sophisticated reserve/
release mechanisms are in the pipeline. IOWs a solution to
your problem now could be an impediment a few years down the
track.

> If not then are there any plans to support reserve/release SCSI command
> so that sg driver can provide these options for its users in its
> open/close function  It will make all I/O operation with sg driver more
> reliable especially in data storage area.

I'm getting this request from several angles. As someone
wryly pointed out ... as if we haven't got enough trouble
at the moment with the scsi subsystem implicitly issuing
scsi commands :-)

Seriously, I don't think issuing reserve/release SCSI commands
on the open and close of a pass-through interface is a good
idea. At a stretch it could be a non-default parameter on the
sg driver [lk 2.4 via /proc/scsi/sg; in lk 2.6 ...]


Just thinking about the implementation: currently sg will hold
its data structures alive if an unexpected close (e.g. user
control-C) occurs while a SCSI command is in flight. I guess
the point of what you are suggesting is to issue another scsi
command (i.e. release) in such a situation (and wait for
it (potentially as well as a command in progress)).

Doug Gilbert

Re: SCSI reserve / release support for SG

[Mike Anderson]

Douglas Gilbert [dougg@torque.net] wrote:
> >If not then are there any plans to support reserve/release SCSI command
> >so that sg driver can provide these options for its users in its
> >open/close function  It will make all I/O operation with sg driver more
> >reliable especially in data storage area.
> 
> I'm getting this request from several angles. As someone
> wryly pointed out ... as if we haven't got enough trouble
> at the moment with the scsi subsystem implicitly issuing
> scsi commands :-)

Yes, a sub question in the following bugme bug also asks this question.
http://bugme.osdl.org/show_bug.cgi?id=1488

> 
> Seriously, I don't think issuing reserve/release SCSI commands
> on the open and close of a pass-through interface is a good
> idea. At a stretch it could be a non-default parameter on the
> sg driver [lk 2.4 via /proc/scsi/sg; in lk 2.6 ...]
> 

Doing a reserve operation on open is more than sg doing some action as
device state could have been altered without sg or any upper level
driver knowing about. This could cause a case where the reservation
would be lost, but upper level drivers would not be notified. I guess
you could use persistent reserves, but then you would need another
parameter for the key. If we need to do these actions plus revoking /
breaking reservations what is the gain of sg doing this on open vs.
doing this in user space. In theory I guess a device mapper target could
be created if someone was opposed to a user space daemon (this is just a
quick thought with very little investigation).

IIRC when updates where happening for scsi_error in relation to door
lock someone suggested that we need a general machanism to indicate what
state the device is in and restore it post recovery.

-andmike
--
Michael Anderson
andmike@us.ibm.com