Re: Handling multiple paths to enclosure devices?

[James Bottomley <James.Bottomley@HansenPartnership.com>]

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).

James