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.
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.
> 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.
Regards -- Andy
[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?
--
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
