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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Linux SCSI]     [Linux RAID]     [Linux Clusters]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]

  Powered by Linux