On Mon, Apr 5, 2010 at 2:15 PM, FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx> wrote: > On Mon, 5 Apr 2010 14:09:45 +1000 > ronnie sahlberg <ronniesahlberg@xxxxxxxxx> 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
