> So this configuration should form a single wide port and thus not > actually be multiple paths. However, if you have two HBAs instead of > one (or a non-SAS HBA), I grant it becomes multipath. Yeah ... actually my case is an HBA with two wide (4-lane) ports, where either the expander or the HBA is not able to fuse them into a single 8-lane port. But clearly this can happen at least with two HBAs pretty easily. > 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? - R. -- 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
