Douglas Gilbert [dougg@xxxxxxxxxx] 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@xxxxxxxxxx
-
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
|
