Re: [PATCH 1/1] Readonly disk LUNs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Mar 9, 2010 at 4:13 PM, FUJITA Tomonori
<fujita.tomonori@xxxxxxxxxxxxx> wrote:
> On Tue, 9 Mar 2010 15:32:48 +1100
> ronnie sahlberg <ronniesahlberg@xxxxxxxxx> wrote:
>
>> For DISK devices, this is communicated back to the initiator by setting the WP bit in teh device specific byte in the mode sense header.
>> It will also fail any WRITE6/10/12/16 calls with a DATA_PROTECT/ASC_WRITE_PROTECT
>>
>> The manpage for tgtadm has been expanded with a PARAMETERS section and the readonly parameter is added as the first parameter for this section.
>>
>> Signed-off-by: Ronnie Sahlberg <ronniesahlberg@xxxxxxxxx>
>> ---
>>  doc/htmlpages/tgtadm.8.html |   33 +++++++++++++++++++++++++++------
>>  doc/manpages/tgtadm.8       |   35 +++++++++++++++++++++++++++++++----
>>  doc/tgtadm.8.xml            |   43 +++++++++++++++++++++++++++++++++++++++++--
>>  usr/sbc.c                   |    9 +++++++++
>>  usr/spc.c                   |   18 +++++++++++++++++-
>>  usr/tgtd.h                  |    1 +
>>  6 files changed, 126 insertions(+), 13 deletions(-)
>
> (snip)
>
>> diff --git a/usr/spc.c b/usr/spc.c
>> index 14a3ee1..25ff849 100644
>> --- a/usr/spc.c
>> +++ b/usr/spc.c
>> @@ -567,8 +567,18 @@ int spc_mode_sense(int host_no, struct scsi_cmd *cmd)
>>
>>       if (mode6) {
>>               data[0] = len - 1;
>> +
>> +             /* device specific parameters */
>> +             if (cmd->dev->attrs.readonly)
>> +                     if (cmd->dev->attrs.device_type == TYPE_DISK)
>> +                             data[2] |= 0x80;
>
> I'm very reluctant to have
>
> if (cmd->dev->attrs.device_type == TYPE_something)
>
> in spc.c. tgt is designed not to do such with struct
> device_type_operations. I guess that sbc_mode_sense would be not a
> good idea too since it would be similar to spc_mode_sense.
>
> But my real question is, for what setting a sbc device to read-only is?

I dont understand your question, so please expand.

Is it "why would anyone want a read-only disk and why would anyone
want to do this",
or "what/how makes a disk device readonly according to the scsi protocol"  ?


If it is the second :
A scsi disk that is readonly, for example through a jumper on a disk
or that little readonly/lock thingy/switch on the usb memory stick,
this causes the disk to refuse any write operations and fail them with
a sense code.
This readonly property is also communicated back to the initiator
through the "device specific" byte of the mode sense header.

Why they put this property in a device type specific bit in the mode
sense header instead of a bit in one of the inq pages, like removable,
I dont know.

Would you rather want a device template specific function to create
the device specific byte? I can do that but think it would be
overkill.



For disk devices, this it the bit 0x80 in the "device specifc parameters.
This is in SBC 6.3.1.

This entire byte is device specific and as far as i know applies to
both SBC == disk and SSC == tape devices both using bit 0x80 to
indicate the device is readonly.
Other devices such as CD ==mmc has this device specific byte as
reserved and must be zero. The report writeability differently.


This particular byte in the mode sense header depends on the type of
device, so i think we really needs an if device == TYPE   or a switch
(device) here.


regards
ronnie sahlberg
--
To unsubscribe from this list: send the line "unsubscribe stgt" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux SCSI]     [Linux RAID]     [Linux Clusters]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]

  Powered by Linux