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

[ronnie sahlberg]

On Mon, Apr 5, 2010 at 2:15 PM, FUJITA Tomonori
<fujita.tomonori at lab.ntt.co.jp> wrote:
> On Mon, 5 Apr 2010 14:09:45 +1000
> ronnie sahlberg <ronniesahlberg at gmail.com> wrote:
>
>> 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.
>
> We also lost persistent reservation, unit attention, etc. Yeah, it
> works for some environments, but I don't recommend such workaround.
>


Ok.

So you would recommend that it would be one single target and then an
ACL-like setting on a per initiator basis
to control readwrite/readonly access to the lun.

a,
The simple way would then be to create some setting/mechanism where
one could control this from one single target but on a
per initiator basis. Kind of like the ACLs, but while ACLs work on a
target, this setting would work on a Target+Lun basis.

b,
Something that would be a lot more work, since it would require a lot
of additional infrastructure would be a question of
1, "how to keep metadata in sync across multiple targets",
or, since we support multiple concurrent instances of tgtd :
2, "how to keep metadata in sync across multiple separate
processes/instances of tgtd."

That would require a bit more infrastructure work inside tgtd, perhaps
like we did with samba,
move all internal state and metadata into TDB databases shared across
all processes.


I think b, would be very attractive, but would be a lot of work.


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