[ofa-general] srp_daemon and partitions.

[David McMillen]

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.

Dave


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/general/attachments/20090609/46acf00a/attachment.html>