On 24/07/2012 18:23, Andy Grover wrote: > On 07/24/2012 12:03 AM, Chris Boot wrote: >> On 24/07/12 01:37, Andy Grover wrote: >>> On 07/23/2012 05:04 PM, Stefan Richter wrote: >>>> But there is a patch pending and planned to be released in v3.6-rc1 which >>>> adds a sysfs attribute that tells whether a node is local or remote. >>> Great! I'll plan on using this. >> Before you do, it's worth noting that the GUIDs/EUI64s used when >> creating the target are a different creature to the firewire device GUID >> in /sys/bus/firewire/devices/*/guid. You can mave many targets to a >> single fw_device, and each target must have a unique GUID. IIRC the >> standard does not mention if the target and device GUIDs should match or >> differ. >> >> The target GUID exists to differentiate firewire targets themselves and >> is an optional part of the SBP specs. Normally (on a physical firewire >> hard disk for example), you can identify a unit from the parent devices >> GUID _and_ the offset of the unit in the owning node's unit directory. >> In our case the offset can change regularly, units can be swapped >> around, all sorts - so the GUID is the only way to uniquely identify one >> target from another. The standard also mentions the scenario where the >> same target may be exposed on multiple fw buses (e.g. with 2 fw cards in >> one system; thus having two fw device IDs), and the GUID is required in >> that scenario so that initiators know they are in fact the same target >> and choose one or the other or multipath or whatnot. > OK just to be clear: > > in 1394-speak (plz correct if I am wrong): > > a device can be local or nonlocal > a device must have a guid > a device's guid never changes > a device can have 1+ targets > a target is a block volume, mountable, etc > a target can optionally have a guid > a target guid (if present) also never changes > a target's parent node and offset in parent node can change > > In LIO-speak: > > (ignoring nodeACLs and lun mapping) > > a host has storageobjects > storageobjects are local files or block devices to export > a host has fabrics > a fabric is a type of scsi transport, such as sbp or iscsi > a fabric can have multiple targets > a target has a unique WWN, and usually matches the > underlying hardware ID (all except iscsi and loop) > a target may have separately-configurable logical targets called TPGs > a TPG has 1+ storageobjects > each associated storageobject has a number, a LUN > the storageobject-LUN association may change > the only way to tell you are accessing the same storageobject is > to send INQUIRY for VPD 83 > > So, a "1394:device" is equivalent to a "lio:target", and a 1394:target > is equivalent to a lio:lun, I believe. No: a "1394:target" is more like a TPG, it can have several LUNs. Really, you have a 1394:device that can contain several 1394:unit_directory, each of which could be an SBP target or something else (an audio device for example). The 1394:unit_directory for an SBP target can export one or more LUNs. > I don't think LIO cares about 1394:target guids at all[1]. We just need > the 1394:device guids so we can be clear on a system with multiple local > 1394 cards exactly which one we're exporting 1394:targets over. Indeed LIO doesn't care a jot about the 1394:target GUIDs at all. It does care about the SBP target directory GUIDs as it has to set them. My SBP target code requires one to create an SBP unit directory, for example - it cannot guarantee that the unit directory location will stay constant in the fw device configuration space or that there won't be 2 FW buses connected to the target machine. >> So really what I'm trying to say is I don't think selecting from the >> existing fw device GUIDs is the right angle to take. In my view, any >> EUI64 with the 'locally administered' bit set should be fair game and >> possibly also those with certain vendor prefixes that we might be >> permitted to use in this scenario (Rising Tide's? the KVM one?). > Is this a theoretical or practical point? LIO allows the admin to enter > nonexistent GUIDs for lio:target WWN, but since there is no physical > device that will match, this is useless. The LIO admin tool > tab-autocompletes WWNs based on what is present in the machine when > creating a lio:target, since that's usually what the admin wants to > configure. You can create an SBP target with any GUID you like, and the code will happily export it and it will be usable from any initiator. > [1] Well like you said, only for multipath scenarios where multiple > 1394:targets represent the same storageobject. Since lio already has a > unique wwn for each storageobject, is that what the sbp fabric is > returning for 1394:target guid? If you really wanted to multipath you would ignore the FW target's GUID and use the WWN on individual LUNs, of course. But if you didn't have such niceties as WWNs (as you may not have done at the time of SPC-2 when SBP was thought of - I don't know) how do you tell one target on one bus is or isn't the same as another target on a different bus? Or two targets on the same device? HTH, Chris -- Chris Boot bootc@xxxxxxxxx -- 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
