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

[ronnie sahlberg]

On Sun, Apr 4, 2010 at 6:11 PM, FUJITA Tomonori
<fujita.tomonori at lab.ntt.co.jp> wrote:
> On Sun, 4 Apr 2010 18:06:39 +1000
> ronnie sahlberg <ronniesahlberg at gmail.com> wrote:
>
>> On Sun, Apr 4, 2010 at 5:39 PM, FUJITA Tomonori
>> <fujita.tomonori at lab.ntt.co.jp> wrote:
>> > On Sun, 4 Apr 2010 08:50:54 +1000
>> > ronnie sahlberg <ronniesahlberg at gmail.com> wrote:
>> >
>> >> There was a few minor details that would require re-working in my patch.
>> >> For example "leaking" devicespecific code out into the spc
>> >> mode-sense6/10 commands
>> >> that would have to be done slightly differently.
>> >
>> > Just make sure that we all are on the same page. His requirement is
>> > more complicated than your patch; read-only attribute "on
>> > per-initiator basis". Probably, we need to extend the current security
>> > model, all-or-nothing on per-initiator basis if we really want this.
>> >
>>
>> True.
>>
>> For many dedicated HW platforms, you have one single taget that
>> represents the entire device  and then using per LUN ACL rules to do
>> remapping of LUN numbers on a per initiator basis or similar.
>> That is when you often have per initiator ro mappings and even per
>> initiator lun number remappings.
>>
>>
>>
>> Software based targets like TGTD often have the possibility to create
>> unlimited number of targets and thus can solve the same issue by
>> target-level ACLs instead of per lun/initiator ACLs.
>>
>>
>>
>> Craig,
>> While not exactly as you are used to in what I assume are HW based
>> iscsi boxens, instead of having readwrite/readonly settings based on
>> the initiator level, would this be acceptable to your problem space ?
>>
>>
>> You create TWO targets,   iqn.2010-04:readwrite and iqn.2010-04:readonly.
>> On both these two targerts you create a LUN that uses the same backing
>> store. I.e. two targets bot both use the same physical LUN.
>> On the readonly target you flag this LUN as reaonly.
>>
>>
>> Now you then use targetlevel ACLs and allow only readwrite initiators
>> to access the readwrite target   but not the readonly target.
>> You also use ALCs to make sure readonly initiators can only access the
>> readonly target but not the readwrite target.
>>
>>
>>
>> I.e.   difference in mechanism   but policy still available. On target
>> lever instead of per lun acl level.
>>
>>
>>
>> Something like this:
>>
>> # create readwrite target and lumn
>> tgtadm --lld iscsi --mode target --op new --tid 1 -T iqn.2010-03:readwrite
>> tgtadm --lld iscsi --mode logicalunit --op new --tid 1 --lun 1 -b
>> /backend-disk.img
>>
>> # create a second target that is readonly but exports the same backing store
>> tgtadm --lld iscsi --mode target --op new --tid 2 -T iqn.2010-03:readonly
>> tgtadm --lld iscsi --mode logicalunit --op new --tid 2 --lun 1 -b
>> /backend-disk.img
>> tgtadm --lld iscsi --mode logicalunit --op update --tid 2 --lun 1
>> --params readonly=1
>
> This doesn't work for tgt since two targets doesn't share information
> about the lu. For example, the mode page changed via the first target
> can be seen via the second target.
>

For readonly devices, exported through two different targets I think
it is ok if the targets do not share the same
metadata such as modepages.

I would see this as "two targets, two luns"  but the readonly luns on
the readonly target just have that special property of automatically
have its content updated when "that other lun" on the readwrite target
is updated.


For now I think this is fine. With a readonly lun, there is no need to
make modepages writeable, and maybe one should even disallow mode
select completely for these.
For that case I think it is actually the most desireable behaviour to have :
*  read-write target can update mode pages. These changes are not
visible to the readonly target.
*  readonly target can do mode select at all and get whatever is set
in targets.conf.



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