[ofa-general] srp_daemon and partitions.

[Vladislav Bolkhovitin]

David McMillen, on 06/10/2009 07:07 AM wrote:
> Chris Worley wrote:
>> On Thu, Nov 20, 2008 at 1:06 PM, Vu Pham <vuhuong at mellanox.com <http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general>> wrote:
>> >/
>> />/ Hi James,
>> />/
>> />/ it's srp_daemon and ibsrpdm bug. We'll try to fix it to provide zoning thru pkey.
>> /
>> I don't think pkeys are the answer to zoning, as I don't see a way to
>> tie a specific disk or partition to a pkey.   At one point I tried to
>> tie IB ports to pkeys, but found that all levels of the SRP stack
>> needed to be pkey-aware.  It looks like a daunting task, and probably
>> not what pkeys were intended to do.
>>
>> I think SCST "security groups" are the intended way to zone.  The
>> scst/README says:
>>
>> ...
>>   2. Initiator-oriented. In this mode you define which devices and
>> their LUNs are accessible for each initiator. In this mode you should
>> createfor each set of one or more initiators, which should access to
>> the same set of devices with the same LUNs, a separate security group,
>> then add to it available devices and names of allowed initiator(s).
>> ...
>> # echo "add_group
>> Default_iqn.2007-05.com.example:storage.disk1.sys1.xyz"
>> >//proc/scsi_tgt/scsi_tgt
>> /# echo "add dev1 0"
>> >//proc/scsi_tgt/groups/Default_iqn.2007-05.com.example:storage.disk1.sys1.xyz/devices
>> /# echo "add dev2 1"
>> >//proc/scsi_tgt/groups/Default_iqn.2007-05.com.example:storage.disk1.sys1.xyz/devices
>> /
>> # echo "add_group spec_ini" >/proc/scsi_tgt/scsi_tgt
>> # echo "add iqn.2007-05.com.example:storage.disk1.spec_ini.xyz"
>> >//proc/scsi_tgt/groups/spec_ini/names
>> /# echo "add dev2 0" >/proc/scsi_tgt/groups/spec_ini/devices
>> ...
>>
>>  But, I don't  understand how the zoning example selects the initiator
>> visibility... I'd hope w/ IB this could be done w/ the port GUID of
>> the initiator.  The example uses the name of
>> "iqn.2007-05.com.example:storage.disk1.spec_ini.xyz" to specify the
>> initiator.  I'm guessing "iqn.2007-05.com.example" specifies the host
>> name of the initiator, but not a clue what
>> "storage.disk1.spec_ini.xyz" means.
>>
>> Chris
> You got pretty close.  I think there is at least one typographical error 
> in the explanation above, but let me try to explain it differently.
> 
> The groups are used to create different sets of LUNs that are presented 
> to the initiators that match a group.  When a login request comes in, 
> scst is asked to find the group given a name.  You can get scst to 
> output a message like
> 
>     Using security group "Default" for initiator "xxx"
> 
> on the console.  The value in "xxx" (not really xxx, but dependent upon 
> the target code using scst) is matched against all of the entries in the 
> "names" pseudo file under each group's directory.  The first group that 
> matches is the winner.  The LUNs defined by the entries in the "devices" 
> pseudo file under that same group will be the only LUNs seen for that 
> session.  If no group has a line in "names" that matches, then the group 
> "Default" is used.  There is a "names" pseudo file here but it's 
> contents are ignored -- everybody is a winner matching the Default group.
> 
> The name of the group is completely arbitrary and meaningless to scst 
> other than to differentiate groups.  If you intend to have a unique 
> group for every initiator, then you could use the same value you will 
> write to "names" as the name of the group, but you could just as easily 
> just generate random names that are unique.
> 
> If you want a particular LUN to show up in more than one group, you have 
> to add it to "devices" for every group that will use it.  Also, if you 
> want that LUN to have the same LUN number, you have to arrange that as well.
> 
> It is probably worth noting that there can be problems if a group does 
> not have a device defined for LUN 0.  It works, but there are initiators 
> and user-level programs that issue SCSI commands and expect to get 
> something when LUN 0 is addressed.  All real devices have some kind of 
> response at LUN 0, even if it is an odd SCSI device or a zero byte / 
> offline disk.
> 
> Back to the "xxx" mentioned above, I don't know what the code you have 
> uses as the key for scst to find a group.  That is why I suggested you 
> check your dmesg output, and you might have to enable some verbose/debug 
> output.  I believe this changed at least once, and in our implementation 
> we are reworking it so we can have highly selective LUN masking against 
> the initiator/target pair.

This is an excellent explanation! I can only add to it that "xxx" is a 
transport specific name. For iSCSI it is an iSCSI name, like 
iqn.2007-05.com.example:storage.disk1.spec_ini.xyz, for SRP it is a port 
name.

> Dave
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> general mailing list
> general at lists.openfabrics.org
> http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
> 
> To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general