Multi-port path topology example:
Zone 1 Zone 2
|-----------------| |----------------|
| HD1 ..... HD25 | | HD26 ......HD50|
| |==================================| |
| | | | | |
| | Expander | |
| |==================================| |
| | | | | |
|-----------|-----| |----|-----------|
x8| |x8
_______|______________|_______
| HBA |
|____________________________|
In this topology, zoning is enabled in such a way that drives from HD1
to HD25 are accessible only through zone1 and drives from HD26 to HD50 are
accessible only through zone2. Here the first x8 connection bw HBA to
Expander in zone1 will have one PortID and second x8 connection bw HBA to
Expander in Zone2 will another PortID.
Problem statement:
When zoning is enabled in expander then we will have two expander
instances (for a single real expander), one instance is accessible through
the first x8 connection and second instance is accessible through
second x8 connection from HBA. But for both the instances the
SAS Address of the expander will be the same.
But in current mpt3sas driver, driver add's only one expander instance,
when second expander instance's 'add' event comes then driver ignores
this event assumues that it is duplicate instance as it already
has a sas_expander object in it's sas_expander_list list with
the same SAS Address. So in this topology users will see only 25 drives
instead of 50 drives.
Current mpt3sas driver use ‘SAS Address’ as a key to uniquely identify
the End devices or Expander devices, but on the multi-port path topologies
(such as above topology) HBA firmware will provide multiple device entries
with different Device handles for a single device.
So here driver can't use ‘SAS Address’ as a key instead driver can use
‘SAS Address’ & ‘PhysicalPort (i.e. PortID)’ number as key to uniquely
identify the device.
where, PhysicalPort is a HBA port number through which the device is
accessible.
Solution:
Now driver uses both 'SAS Address' & 'PhysicalPort' number as a key to
uniquely identify the device object from the corresponding device
list's. So, when 'add' event comes for second instance of expander,
now driver can't find the sas_expander object with same 'SAS Address' &
'PhysicalPort' number (since for this second instance PhysicalPort
number will be different from first instance's PhysicalPort number)
from the sas_expander_list list. So the driver processes this event and
will create a new sas_expander object for this expander instance
and adds it sas_expander_list.
With this solution, the driver will have two sas_expander objects, one
object is for the first instance of the expander, another object is for
second instance of the driver. Now users will access all 50 drives from
above topology.
Like device SAS Address, PhysicalPort number is readily available
from below config pages,
* SAS IO Unit Page 0,
* SAS Device Page 0,
* SAS Expander Page 0,
* SAS Phy Page 0, etc
Through this patch set, the driver now manages the sas_device &
sas_expander objects using 'SAS Address' & 'PhysicalPort'
number as key.
Sreekanth Reddy (14):
mpt3sas: Define hba_port structure
mpt3sas: Allocate memory for hba_port objects
mpt3sas: Rearrange _scsih_mark_responding_sas_device()
mpt3sas: Update hba_port's sas_address & phy_mask
mpt3sas: Get device objects using sas_address & portID
mpt3sas: Rename transport_del_phy_from_an_existing_port
mpt3sas: Get sas_device objects using device's rphy
mpt3sas: Update hba_port objects after host reset
mpt3sas: Set valid PhysicalPort in SMPPassThrough
mpt3sas: Handling HBA vSES device
mpt3sas: Add bypass_dirty_port_flag parameter
mpt3sas: Handle vSES vphy object during HBA reset
mpt3sas: add module parameter multipath_on_hba
mpt3sas: Bump driver version to 35.101.00.00
drivers/scsi/mpt3sas/mpt3sas_base.h | 102 +-
drivers/scsi/mpt3sas/mpt3sas_ctl.c | 6 +-
drivers/scsi/mpt3sas/mpt3sas_scsih.c | 1237 +++++++++++++++++++---
drivers/scsi/mpt3sas/mpt3sas_transport.c | 312 +++++-
4 files changed, 1455 insertions(+), 202 deletions(-)
--
2.18.4
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
