Re: What does cache_dynamic_acls parameter do?

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

 



Andy, Jerome thanks for the explanation of what the dynamic acls are.
Please see my comment regarding cahe_dynamic_acls in the context
below.

On Wed, Oct 15, 2014 at 4:06 AM, Jerome Martin <jxm@xxxxxxxxxxx> wrote:
> On 10/15/2014 03:02 AM, Andy Grover wrote:
>>
>> On 10/13/2014 08:37 PM, Rufe Glick wrote:
>>>
>>> Hello all,
>>>
>>> I'm just starting to learn the targetcli. Examples on internet that
>>> set up 'TPG demo mode' along with authentication=0,
>>> generate_noide_acls=1 and demo_mode_write_protect=0 parameters use
>>> cache_dynamic_acls=1. I figured what the first three parameters do,
>>> but I can't find information on the fourth - cache_dynamic_acls. Can
>>> someone please explain me what does that parameter do. Also what are
>>> dynamic acls?
>>
>>
>> I think dynamic acls are those that are created when generate_node_acls
>> is true -- they're not created through configfs but they exist because
>> the code requires an ACL to exist for every initiator.
>
>
> This is correct.
>
> By default, each initiator who wants to connect to a target needs to have a
> corresponding ACL, allowing the initiator WWN to connect. We have a "demo
> mode" though, which basically allows any initiator to connect. This works by
> creating node ACLs on-the-fly internally and corresponds to the
> generate_node_acls attribute set to 1.
>
>> I did a quick grep of the code and it didn't seem to me like
>> cache_dynamic_acls actually affects Lio's behavior, but maybe I missed
>> something.
>
>
> Here is my understanding.
>
> When dynamic ACLs are used (generate_node_acls == 1), se_node_acls structs
> are created on-the-fly for initiators. The cache_dynamic_acls=1 effect is to
> keep those around and reuse them instead of re-creating new ones. From a
> functional standpoint, this has an effect on the persistence of some SCSI
> persistent reservations operations.
>
> However, since a couple of years or so, when generate_node_acls is set to 1
> and cache_dynamic_acls is set to 0, the iSCSI kernel code should detect it
> and set cache_dynamic_acls to 1 in the iscsi_tpg_attrib struct internally,
> allowing reservation code to reuse dynamic ACL structures when they already
> exist.

So when generate_node_acls is set to 0, the cache_dynamic_acls setting
has no effect by definition. When generate_node_acls is set to 1, the
cache_dynamic_acls is set to 1 by the kernel anyway. So maybe you
shouldn't expose that configuration parameter in the targetcli
altogether? Or do you keep it there for compatibility reasons? Then
you could at least mark it as obsolete in the man page and in the
short description available in the targetcli by typing 'get attribute'
+ Enter in the TPG context.

Thanks,
Rufe
--
To unsubscribe from this list: send the line "unsubscribe target-devel" 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]     [Kernel Newbies]     [Linux SCSI Target Infrastructure]     [Share Photos]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Device Mapper]

  Powered by Linux