On Fri, 2012-02-10 at 10:39 +0000, Chris Boot wrote: > On 9 Feb 2012, at 23:51, Stefan Richter wrote: > <SNIP> > >> I just posted a commit to my github repo which does the following: > >> > >> 1. Maps SAM target ports to IEEE-1212 units. > >> 2. Insists that a target port within the target framework is named using > >> an EUI-64/GUID and exposes this in the IEEE-1212 unit directory's > >> Unit_Unique_ID property. > > > > So now we need to support unit unique ID in our initiator too. > > I can volunteer to do that if you like. I could prepare a patchset for > firewire-sbp2 including taking notice of Unit_Unique_ID, ignoring the > local node and fixing a couple of minor issues in > sbp2_status_to_sense_data() where we mishandle the VALID, MARK, EOM > and ILI bits. > > As for my target code, should I be including an explicit Directory ID > as part of my target port name in the target? It seems as though > that's something that should be settable seeing as the directory is > not necessarily in a constant location in the config ROM at all - but > making the target ports that long and complex seems a bit harsh, > especially considering all the rules that go along with it... An > example target port name in this case could be: > > 5254000b8f01e6f6:000000 > If a SCSI over IEEE 1394 target port WWN value is only coming from hw and userspace is *not* formatting their own virtual WWPNs (eg: iscsi_target), then under /sys/kernel/config/target/ a fabric typically will enforce the use of a single $FABRIC/$TARGET_WWPN/tpgt_1/ per physical HW port. If the ':000000' suffix above is an optional user-generated fabric dependent value, then one option is to map it to existing se_portal_group->tpg_group level ($FABRIC/$TARGET_WWPN/tpgt_1/), and encode the user-generated ->tpgt value into the directory ID suffix presented on the wire. > I would have to ensure the directory ID was unique in my target code > (or even the whole firewire subsystem) as well as make sure it was not > between 0x400 and 0x43f (the range of possible implicit directory IDs > in Juju) as IEEE-1212 says "The value of directory_ID in a > Directory_ID entry shall be unique among all of a node’s directory > IDs, both explicit and implicit." > To give an idea of how this looks from the library level, here is how /var/target/fabric/qla2xxx.spec options are used to read+parse input from sysfs to determine available ports for tcm_qla2xxx: <SNIP> # The module uses hardware addresses from there wwn_from_files = /sys/class/fc_host/host*/port_name # Transform '0x1234567812345678' WWN notation to '12:34:56:78:12:34:56:78' wwn_from_files_filter = "sed -e s/0x// -e 's/../&:/g' -e s/:$//" <SNIP> the output presents the available FC HW ports in fabric dependent notation into rtslib code. Here is how it looks from the top-level of rtsadmin, and how the ports are presented to shell users for <TAB> completion creation, et al: /> qla2xxx/ info Fabric module name: qla2xxx ConfigFS path: /sys/kernel/config/target/qla2xxx Allowed WWNs list (free type): 21:00:00:24:ff:31:4c:49, 21:00:00:24:ff:31:4c:48 Fabric module specfile: /var/target/fabric/qla2xxx.spec Fabric module features: acls Corresponding kernel module: tcm_qla2xxx > To me it feels like SBP-2/3 wanted the Unit_Unique_ID to be the > identifier by itself (falling back to the node's GUID if that entry > was not present), but SAM seems to ignore the Unit_Unique_ID and go > for a combination of the node's GUID and the Directory_ID as would > have been by IEEE-1212's design. Confusing. > Mmmmm.. > There is also an added difficulty in that a directory can't be added > to a single card's Config ROM in Juju, but instead is added to all > cards on the system. This is why I think it's important to include an > explicit Unit_Unique_ID, as if you have two cards possibly on the same > bus an initiator would see the two units on different nodes as > different units instead of two instances of the same unit. > > What does everyone think? > That sounds like a good reason use Unit_Unique_ID then.. ;) So in sbp_configfs.c code, sbp_make_tport() is currently not doing any type of HW port setup, which happens later in the next configfs group down via sbp_make_tpg() -> sbp_management_agent_register() For /sys/kernel/config/target/sbp/$SBP_WWPN registration, it would be cleaner to do HW target port init earlier in sbp_make_tport() and then use sbp_make_tpg() for an optional per port tag. If you don't want the tag user configurable, enforce a single /sbp/$SBP_WWPN/tpgt_1 from within sbp_make_tpg() and don't encode anything extra based on the tag in $SBP_WWN.. > >> 3. Limits the SAM target port to only contain one TPG (target port > >> group), which I believe only really make sense for iSCSI. > > Correct, iSCSI Target Portal Groups and ALUA Target Port Groups are two different things. The former is used to create multiple iSCSI target ports off a single iSCSI Qualified Name (IQN), and the latter is a fabric independent construct for per device implict/explict asymmetric logical unit access for multipath and other purposes. The /sys/kernel/config/target/$FABRIC/$FABRIC_WWN/tpgt_X usage in target_core_fabric_configfs.c is actually a remnant of the original design, and for non-iscsi fabrics is hidden from user in the rtsadmin/targetcli shell. > > OK... So this is about multipathing, but not iSCSI specific in principle. > > SAM allows a logical unit to be reached through more than one target port. > > Building on that, SPC-3/-4 defines > > - target port asymmetric access state: The characteristic that defines > > the behavior of a target port and the allowable command set for a > > logical unit when commands and task management functions are routed > > through the target port maintaining that state, > > - target port group: A set of target ports that are in the same target > > port asymmetric access state at all times. > > A logical unit which canbe reached through a whole bunch of target ports > > can some of those ports into groups. Some details are specified in > > SPC-3/-4 section 5.8 in a transport-agnostic manner. A transport > > specification would certainly need to offer a mapping for all that. > > SBP-2/-3 doesn't. > Correct. target-core does fully support implict/explict ALUA for virtual backends across all fabrics (by default) including the current firewire-sbp-target.ko code.. Configuration for this is done on a per device context under /sys/kernel/config/target/core/$HBA/$DEV/alua/ using different $HBA/$DEV/alua/$ALUA_TG_PT_GP_NAME. By default during creation, each fabric LUN is associated with the device's default_tg_pt_gp. Here is how things look with 4 LUNs across 3 different fabrics under one iblock backend: target# cat /sys/kernel/config/target/core/iblock_0/mpt_fusion/alua/default_tg_pt_gp/members iSCSI/iqn.2003-01.org.linux-iscsi.debian-amd64.x8664:sn.1bc6fcb58f24/tpgt_1/lun_0 iSCSI/iqn.2003-01.org.linux-iscsi.debian-amd64.x8664:sn.6747a471775f/tpgt_1/lun_1 loopback/naa.6001405df1bafb29/tpgt_1/lun_0 vhost/naa.60014050088ae39a/tpgt_1/lun_0 --nab -- 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
