SCSI reserve / release support for SG
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.
Signature · 11 lines
Thanks -Sachin ----------------------------------- Sachin Sant Linux Technology Center IBM Software Lab Bangalore, INDIA. [email protected] Ph: 91-80-5044647 -----------------------------------
Quoted 1 line · Sachin Sant
Does Current sg driver offer SCSI reserve/release command in its open/close function.
No.
Quoted 2 lines
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.
Quoted 4 lines
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
Quoted 9 lines · Douglas Gilbert [[email protected]] wrote:
Quoted 4 lines
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
Quoted 6 lines
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
[email protected]