Re: Handling multiple paths to enclosure devices?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 07/29/2011 09:09 AM, James Bottomley wrote:
On Thu, 2011-07-28 at 13:57 -0700, Roland Dreier wrote:
  >  My initial thought is that in a multi-path situation, as above, we get
  >  two enclosures appearing as well (one down each path).  If we
  >  incorporated the idea of topological subtrees into the identity matching
  >  code, we'd end up filling each of the enclosures with the path connected
  >  devices.  That seems to be an easy situation for multi-path drivers to
  >  sort out and one requiring no alteration of the existing enclosure code
  >  (except to do the topological subtree search).

Ah, good insight: we do have two copies of the expander device, and so
it would be natural to attach each disk to the expander device on the
same path to that disk.

I'm a bit confused by what you mean about multi-path drivers though --
it would seem we would need the enclosure stuff to handle this
somehow?  It seems that if I have this situation, my HBA driver (eg
mpt2sas) will discover the SCSI bus, hit an enclosure, trigger loading
the ses driver (which pulls in the enclosure driver), and then
continue discovering disks.  And it seems this code needs to get the
topology sorted by itself -- how could a multi-path driver inject
itself into the symlink creation in enclosure.c?

I merely meant that our current philosophy is to layer multi-path
awareness in a separate driver: dm.  There's certainly no expander
awareness in dm-mp at the moment, but there could be.  It should be
quite simple:  match the expanders to something like a dm-exp and then
basically use the slot information in the expander to construct dm
devices for each of the physicals (the rule for dm device creation would
be dm-exp slot matching).

Doesn't help as device-mapper is only concerned with block devices,
what with dm devices being essentially abstract block devices.

But yes, we should stick to our current philosophy of treating multipath devices as separate trees underneath the accessing HBA. We should not (and, in fact, cannot) try to map the external topology in sysfs, rather should stick to a logical view as seen from each HBA. So the enclosure class needs to be updated
int include the HBA number in there to avoid duplicate links.

The correct mapping and accessing these 'multipathed enclosures'
will then be left as an exercise to the reader :-)

Cheers,

Hannes
--
Dr. Hannes Reinecke		      zSeries & Storage
hare@xxxxxxx			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]
  Powered by Linux