How should a "locked" SCSI device behave?

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

* From the T10 Reflector (t10 at, posted by:
* James.C.Hatfield at
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
Also, for the benefit of those without knowledge of how ATA devices do
(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
(e.g. follow Gerry Houlder's concept).
Thank You !!!
Jim Hatfield
Seagate Technology LLC
   e-mail:  James.C.Hatfield at
   s-mail:  389 Disc Drive;  Longmont, CO 80503 USA
   voice:  720-684-2120
   fax....:  720-684-2711
	     Gerry.Houlder at sea													   
	     Sent by:							To 
	     owner-t10 at	       t10 at			   
	     (952) 402-2869						cc 
	     03/23/2007 12:59	       How should a "locked" SCSI device   
	     PM 		       behave?				   
* From the T10 Reflector (t10 at, posted by:
* Gerry.Houlder at
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
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at

More information about the T10 mailing list