Comments on software write protect bit
Gerry_Houlder at notes.seagate.com
Wed Jan 31 17:17:48 PST 1996
* From the SCSI Reflector, posted by:
* Gerry Houlder <Gerry_Houlder at notes.seagate.com>
This is my response to George's comments:
>I have recieved the following comments on your proposal 96-121r0 to
>add a software write protect bit to a mode page for block device types.
>I would like to see these comments reflected in the next version of the
>-Add in the ability to restrict the write protection to a defined
>LBA range. (JD)
The proposal is intended to address the need for an "entire LUN" write
protection scheme. If it is limited to an LBA range, many complications
must be addressed, such as:
1) How many different LBA ranges need to be specified? This answer
has a bearing on the answer to item (3) below.
2) An LBA range makes the mechanism specific to direct access devices.
A "protect entire LUN" mechanism can be shared with other device types.
3) What mechanism should be used? A mode page? A new command
similar to reserve/release?
Actually, the existing Reserve command with extent option is already able to
specify LBA ranges for Read Only areas of the disk. Do we really want to
create a new mechanism that is a subset of this capability?
>-Need to have an explicit list of commands that will return check
>condition when SWP bit is set to one. The suggested list is as
>follows:FORMAT UNIT, REASSIGN BLOCKS, WRITE (6)(10)(12), WRITE AND
>VERIFY (6)(10)(12), WRITE SAME, WRITE LONG, COPY, and COPY AND
I agree that this list should be added to the standard. I believe the best place
is to put it in the models of each device type (because each type has different
command sets). For example, SBC has an "error reporting" section that lists
the Data Protect sense key but doesn't list the commands that can get this
result. Should the list be placed here?
Alternatively, a new section describing the concept of "write protection" could
be added. I see there is a section describing the "removable medium"
concept. Is this better?
A quick check revealed that the individual commands listed above have
nothing in their descriptions about how they behave in presence of a "write
protected" state. So we can't depend on these descriptions.
Note that this will require similar update to all the command set documents
so they are consistent in describing this concept. Everyone needs to answer
this question for themselves: If I wanted to find the effect of write protection
on a device, where would I look to find the information? That spot is where
we should put the information!
>-If there is another way to write protect a device (e.g. switch,
>jumper, etc.) then what takes has priority; the SWP bit or the
I don't think we need to specify any "priority" for the different write protect
mechanisms. This is really a big OR function -- if any one of the
mechanisms specifies write protection, then write protection is active and
the WP bit in the Mode Sense header is set. If the SWP bit is zero, then
the initiator must assume some other mechanism is active, requiring
operator intervention to override it.
More information about the T10