How should a "locked" SCSI device behave?

James.C.Hatfield at seagate.com James.C.Hatfield at seagate.com
Fri Mar 23 14:12:35 PDT 2007


* From the T10 Reflector (t10 at t10.org), posted by:
* James.C.Hatfield at seagate.com
*
Did you really mean 'status code' ? or sense key ?
If 'sense key' was your intent, then there are already several sense codes
that may work
      ACCESS DENIED - NO ACCESS RIGHTS
      SECURITY ERROR
      LOGICAL UNIT ACCESS NOT AUTHORIZED
------------------------
Also, for the benefit of those without knowledge of how ATA devices do
this,
(and for SAT) there is a major difference being proposed:
ATA   In general, the rule for the ATA 'security feature set' is
      if the command affects any User LBA
	    then abort when the device is locked
		  else allow access when the device is locked
SCSI (proposed)
      is based on the 'exclusive reservations' principle (details below)
      This would cause many non-User LBA commands
	    to be check-conditioned as well.
I believe that 'when in SCSI-Land, we should be consistent with SCSI
precedents.
(e.g. follow Gerry Houlder's concept).
--------------------------------------
Thank You !!!
-----------------------------------------------------------------
Jim Hatfield
Seagate Technology LLC
   e-mail:  James.C.Hatfield at seagate.com
   s-mail:  389 Disc Drive;  Longmont, CO 80503 USA
   voice:  720-684-2120
   fax....:  720-684-2711
==========================================
	     Gerry.Houlder at sea						   
	     gate.com							   
	     Sent by:							To 
	     owner-t10 at t10.org	       t10 at t10.org			   
	     (952) 402-2869						cc 
								   Subject 
	     03/23/2007 12:59	       How should a "locked" SCSI device   
	     PM 		       behave?				   
* From the T10 Reflector (t10 at t10.org), posted by:
* Gerry.Houlder at seagate.com
*
I know there is a proposal out there for how to do drive locking on a SCSI
drive but there hasn't been any real discussion on it. I am hoping to start
discussion on the reflector.
(1) The first major question is, what commands should be allowed through a
locked drive?
My idea is to base the list on the "exclusive reservations" behavior. A
locked drive would act the same as a drive reserved exclusively to another
initiator. The only differences would be:
(1a) All the reserve and release commands would be prohibited. We wouldn't
want an initiator that was locked out from drive access to be able to
reserve a command to itself, thus prohibiting another initiator from using
the drive even if it was unlocked for them.
(1b) The Security Protocol In and Security Protocol Out commands would be
allowed. This is the mechanism for locking/ unlocking the drive.
Are there any agreements or disagreements with this?
(2) Next, what should be the drive's response to a locked out command?
(2a) We could just use CHECK CONDITION status and create ASC/ ASCQ
combination stating the drive is locked. In use, this would be similar to
the behavior we have now for accessing an illegal LUN, except that fewer
commands are allowed to an illegal LUN than to a locked LUN [based on my
idea (1) above].
(2b) We could continue following the reservation model and create a new
status code called DEVICE LOCKED. The drive would return this status when
it is locked. This is similar to the behavior we now have for returning
RESERVATION CONFLICT when a drive is reserved.
>From the view of the drive, I don't have a preference for either (2a) or
(2b). (2b) is a little easier because the drive doesn't have to create the
sense bytes but the code change for either is about the same. I suspect
that the initiator end might have a preference, however, based on what
driver layer is expected to handle drive locking behavior. Any opinions out
there?
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org



More information about the T10 mailing list