On Mon, 5 Apr 2010 15:36:29 +0900 FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx> wrote: > On Mon, 5 Apr 2010 16:21:11 +1000 > ronnie sahlberg <ronniesahlberg@xxxxxxxxx> wrote: > > > 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. > > I prefer this. But to be honest, I'm not interested in this feature > much. It would be nice but it's not a must for me. btw, I'm not against merging the feature if someone sends a clean patch of it. Supporting read-only target on a per initiator basis should not complicate the code much. > > 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." > > I will never do this. This needs tons of complicated changes (locking, > etc). It doesn't worth it. As I said before, tgt officially doesn't > support multiple instances. It's the advanced feature for users who > fully knows what they are doing. I don't have any plan to support the current "multiple tgtd processes" feature however it doesn't mean that I'm against using multiple threads (we already do for logical units). We might need to think about using a thread per target or a thread per initiator if necessary. -- 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
