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

ronnie sahlberg ronniesahlberg at gmail.com
Mon Apr 5 08:21:11 CEST 2010

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.


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.

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.

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.

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

More information about the stgt mailing list