Re: RFC, initial prototype to add add/delete/show portals to tgtadm/tgtd

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

 



Tomo,


> Please simply reject if users specify a portal group that isn't
> one. tgt doesn't support portal group now so no point to point non 1
> portal group.
>

Ok,  not implementing any portal group is ok with me.
And keeping everything as 'tgtd only supports one single portal group
and that is #1'
In that case, you really only ask for 'expand the portal structure to
also keep a portal group tag but keep this hardcoded to 1'  ?

Please expand, I think I misunderstand you.


regards
ronnie sahlberg


On Sun, Apr 17, 2011 at 5:02 PM, FUJITA Tomonori
<fujita.tomonori@xxxxxxxxxxxxx> wrote:
> On Sun, 17 Apr 2011 16:10:32 +1000
> ronnie sahlberg <ronniesahlberg@xxxxxxxxx> wrote:
>
>> Ok. I can add setting a portal group tag for each portal, and have it
>> default to ptgt 1
>> by default.
>> That would need some additional changes in the discovery and login
>> processing, but that should not be too painful.
>
> Please simply reject if users specify a portal group that isn't
> one. tgt doesn't support portal group now so no point to point non 1
> portal group.
>
>
>> The biggest question would be of the syntax and how to specify it.
>> The most natural way to specify the tpgt would be using ',<tpgt>'
>>
>> Like :
>> tgtd --iscsi portal=10.1.1.27:3260,1
>>
>> But ',' is already taken for specifying
>> --iscsi portal=10.1.1.27:3260,portal=10.1.1.28:3261
>> or  if other iscsi parameters will be added later.
>>
>> I like being able to specify multiple comma-separated portals using
>> ike that, and also comma-separated other arguments that may be added
>> in the future.
>> But I would also like to retain using ',<tpgt>' since that seems to be
>> the de-facto way to show / describe target portal group tags.
>>
>> Picking a different character as the tpgt would solve the issue but be
>> non-intuitive.
>>
>>
>> Would you be ok with the syntax like this ?
>> portal=<address>[:<port>][,<tpgt>]
>
> I really want to avoid it, a separator character has two meanings. I
> suspect that it will hurt us badly in the future.
>
>
>> Example:
>> --iscsi portal=10.1.1.27:3260
>> --iscsi portal=10.1.1.27:3260,2
>> --iscsi portal=10.1.1.27:3260,2,portal=1.1.27:3262,3
>> --iscsi portal=10.1.1.27:3260,portal=1.1.27:3262,3
>>
>> In this case ',' is sometimes a argument separator and sometimes a
>> tpgt separator.
>> Not optimal but I could live with this syntax.
>>
>> Are you ok with this syntax or would you prefer a different syntax?
>>
>>
>> >
>> > And how can we see the binding of a target and portals
>>
>> I would like to do that part later, once the add/remove portals is
>> finished and merged first.
>>
>> But with TPGT support I could imagine it could be something like
>> * each target is assigned to one single tpgt
>
> Why? Even if I don't have any plan to add such feature, I think that
> we need to add the interface capable of it.
>
>
>> * default is that a target is bound to tgpt:1   but a new tgtadm
>> command could be used to change it
>> * discovery and login support are enhanced to only allow and filter
>> based on the tpgt bound to that target.
>> * discovery checks the portal that the discovery session is bound to
>> and uses this to find which tpgt this portal belongs to
>> this is used to filter the list of returned targets.
>> I.e. if you connected to a portal in tpgt:5   you will only discover
>> targets that belong to that same tpgt. Other targets on other portal
>> groups are not shown.
>> * During login, find which portal group the session connected to and
>> verify that the requested target belongs to that group. Fail the login
>> otherwise.
>>
>> But  lets do the portal groups/targets/...  things later once we have
>> the ability to add / delete portals first.
>>
>>
>>
>>
>> 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
>
--
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