[stgt] [PATCH 1/1] Readonly disk LUNs

[ronnie sahlberg]

On Tue, Mar 9, 2010 at 4:41 PM, FUJITA Tomonori
<fujita.tomonori at lab.ntt.co.jp> wrote:
> On Tue, 9 Mar 2010 16:38:19 +1100
> ronnie sahlberg <ronniesahlberg at gmail.com> wrote:
>
>> > 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",
>
> Oops, that's my question.
>


Ok, initially it was triggered by the other thread bout reaonly for
some initiators.
That is probably a very bad example since there are other issues with
that approach and why it should not be recommended.
I had some free time on my hands and it looked interesting and educationable.


There are three cases I can come up with that would make users want a
readonly disk.

1, share a disk across many initiators as readonly and avoid having
the various initiators write and update atime when a file is accessed.
this is a weak argument since one could just mount the fs with noatime

2, snapshots. many filesystems support fs or file level snapshots.
Many of them only support readonly access to the snapshot device/file.
making the lun signal it is readonly back to the initiator reduces the
amount of surpsrise to an initiator when it does a mode sense and the
device says read-write ok but when it later tries a write to update a
inode atime its getting a sense code back.

3, maybe you just don trust some initiators and just dont want them to
be able to write to the device ?


I think there are usecases where it could be useful.
It is not a very important feature.


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