[PATCH] path_id: Handle SAS and SATA devices

[PATCH] path_id: Handle SAS and SATA devices

[Hannes Reinecke]

SAS devices should be referenced by the SAS address of the target;
on the initiator side we assume an identity mapping between SAS
addresses and PCI devnumber.
SATA devices have an identity mapping between SATA links and
linux scsi_host structures, so we can map the host number onto
the SATA link.
For this to work the LUN numbering needs to be updated, too,
as SATA devices do not have the concept of a LUN, whereas normal
SCSI devices have.

Signed-off-by: Hannes Reinecke <hare@suse.de>

diff --git a/extras/path_id/path_id.c b/extras/path_id/path_id.c
index dcee378..1b6c363 100644
--- a/extras/path_id/path_id.c
+++ b/extras/path_id/path_id.c
@@ -97,7 +97,6 @@ static struct udev_device *handle_scsi_fibre_channel(struct udev_device *parent,
 	struct udev_device *targetdev;
 	struct udev_device *fcdev = NULL;
 	const char *port;
-	unsigned int lun;
 
 	targetdev = udev_device_get_parent_with_subsystem_devtype(parent, "scsi", "scsi_target");
 	if (targetdev = NULL)
@@ -112,8 +111,7 @@ static struct udev_device *handle_scsi_fibre_channel(struct udev_device *parent,
 		goto out;
 	}
 
-	lun = strtoul(udev_device_get_sysnum(parent), NULL, 10);
-	path_prepend(path, "fc-%s:0x%04x%04x00000000", port, lun & 0xffff, (lun >> 16) & 0xffff);
+	path_prepend(path, "fc-%s", port);
 out:
 	udev_device_unref(fcdev);
 	return parent;
@@ -121,7 +119,34 @@ out:
 
 static struct udev_device *handle_scsi_sas(struct udev_device *parent, char **path)
 {
-	return NULL;
+	struct udev *udev  = udev_device_get_udev(parent);
+	struct udev_device *end_dev = NULL;
+	struct udev_device *sas_dev;
+	const char *end_dev_wwn;
+
+	/* Find end device */
+	end_dev = parent;
+	while (1) {
+		end_dev = udev_device_get_parent(end_dev);
+		if (end_dev = NULL)
+			return NULL;
+		if (!strncmp(udev_device_get_sysname(end_dev), "end_device", 10))
+			break;
+	}
+	if (end_dev = NULL)
+		return NULL;
+
+	/* find sas end device */
+	sas_dev = udev_device_new_from_subsystem_sysname(udev, "sas_device", udev_device_get_sysname(end_dev));
+	if (sas_dev = NULL)
+		return NULL;
+
+	end_dev_wwn = udev_device_get_sysattr_value(sas_dev, "sas_address");
+
+	path_prepend(path, "sas-%s", end_dev_wwn);
+
+	udev_device_unref(sas_dev);
+	return end_dev;
 }
 
 static struct udev_device *handle_scsi_iscsi(struct udev_device *parent, char **path)
@@ -174,7 +199,7 @@ static struct udev_device *handle_scsi_iscsi(struct udev_device *parent, char **
 		goto out;
 	}
 
-	path_prepend(path, "ip-%s:%s-iscsi-%s-lun-%s", addr, port, target, udev_device_get_sysnum(parent));
+	path_prepend(path, "ip-%s:%s-iscsi-%s", addr, port, target);
 out:
 	udev_device_unref(sessiondev);
 	udev_device_unref(conndev);
@@ -183,23 +208,34 @@ out:
 
 static struct udev_device *handle_scsi_default(struct udev_device *parent, char **path)
 {
+	struct udev *udev  = udev_device_get_udev(parent);
 	struct udev_device *hostdev;
-	int host, bus, target, lun;
-	const char *name;
+	int host, bus, target;
+	const char *name, *hba, *hostpath;
 	char *base;
 	char *pos;
+	char *type = "scsi";
 	DIR *dir;
 	struct dirent *dent;
-	int basenum;
-
-	hostdev = udev_device_get_parent_with_subsystem_devtype(parent, "scsi", "scsi_host");
-	if (hostdev = NULL)
-		return NULL;
+	int basenum, hostnum = 0;
 
 	name = udev_device_get_sysname(parent);
-	if (sscanf(name, "%d:%d:%d:%d", &host, &bus, &target, &lun) != 4)
+	if (sscanf(name, "target%d:%d:%d", &host, &bus, &target) != 3)
 		return NULL;
 
+	parent = udev_device_get_parent(parent);
+	/* Check for libata hosts */
+	hostdev = udev_device_new_from_subsystem_sysname(udev, "scsi_host", udev_device_get_sysname(parent));
+	if (hostdev = NULL)
+		return NULL;
+	hba = udev_device_get_sysattr_value(hostdev, "proc_name");
+	if (hba && (!strncmp(hba, "sata", 4) || !strcmp(hba, "ahci")))
+		type = "sata";
+	if (hba && (!strncmp(hba, "pata", 4) || !strncmp(hba, "ata", 3)))
+		type = "ata";
+	udev_device_unref(hostdev);
+	/* Reset to original host path */
+	hostdev = parent;
 	/* rebase host offset to get the local relative number */
 	basenum = -1;
 	base = strdup(udev_device_get_syspath(hostdev));
@@ -227,6 +263,7 @@ static struct udev_device *handle_scsi_default(struct udev_device *parent, char
 		if (strncmp(dent->d_name, "host", 4) != 0)
 			continue;
 		i = strtoul(&dent->d_name[4], &rest, 10);
+		hostnum++;
 		if (rest[0] != '\0')
 			continue;
 		if (basenum = -1 || i < basenum)
@@ -239,20 +276,54 @@ static struct udev_device *handle_scsi_default(struct udev_device *parent, char
 	}
 	host -= basenum;
 
-	path_prepend(path, "scsi-%u:%u:%u:%u", host, bus, target, lun);
+	if (!strcmp(type, "scsi"))
+		path_prepend(path, "scsi-%u:%u:%u", host, bus, target);
+	else
+		path_prepend(path, "%s-%u", type, host);
 out:
 	free(base);
 	return hostdev;
 }
 
+static int scsi_is_sata(const char *name)
+{
+	char syspath[UTIL_PATH_SIZE];
+	struct stat stbuf;
+
+	strcpy(syspath, name);
+	strcat(syspath, "/unload_heads");
+
+	return (stat(syspath, &stbuf) < 0) ? 0 : 1;
+}
+
 static struct udev_device *handle_scsi(struct udev_device *parent, char **path)
 {
+	struct udev *udev  = udev_device_get_udev(parent);
 	const char *devtype;
 	const char *name;
 	const char *id;
 
 	devtype = udev_device_get_devtype(parent);
-	if (devtype = NULL || strcmp(devtype, "scsi_device") != 0)
+	if (devtype = NULL)
+		return parent;
+
+	/* lousy scsi sysfs does not have a "subsystem" for the transport */
+	name = udev_device_get_syspath(parent);
+
+	if (strcmp(devtype, "scsi_device") = 0) {
+		if (!scsi_is_sata(name)) {
+			unsigned int host, bus, target, lun;
+
+			if (sscanf(udev_device_get_sysname(parent),
+				   "%d:%d:%d:%d", &host, &bus, &target, &lun) != 4)
+				return NULL;
+			path_prepend(path, "lun-0x%04x%04x00000000",
+				     lun & 0xffff, (lun >> 16) & 0xffff);
+		}
+		return parent;
+	}
+
+	if (strcmp(devtype, "scsi_host") = 0)
 		return parent;
 
 	/* firewire */
@@ -263,9 +334,6 @@ static struct udev_device *handle_scsi(struct udev_device *parent, char **path)
 		goto out;
 	}
 
-	/* lousy scsi sysfs does not have a "subsystem" for the transport */
-	name = udev_device_get_syspath(parent);
-
 	if (strstr(name, "/rport-") != NULL) {
 		parent = handle_scsi_fibre_channel(parent, path);
 		goto out;

Re: [PATCH] path_id: Handle SAS and SATA devices

[Kay Sievers]

On Wed, Jul 7, 2010 at 16:55, Hannes Reinecke <hare@suse.de> wrote:
>
> SAS devices should be referenced by the SAS address of the target;
> on the initiator side we assume an identity mapping between SAS
> addresses and PCI devnumber.
> SATA devices have an identity mapping between SATA links and
> linux scsi_host structures, so we can map the host number onto
> the SATA link.
> For this to work the LUN numbering needs to be updated, too,
> as SATA devices do not have the concept of a LUN, whereas normal
> SCSI devices have.

David, any chance to give this a try on your SAS box, and see if this
works as expected for you too?

Thanks,
Kay

Re: [PATCH] path_id: Handle SAS and SATA devices

[Harald Hoyer]

Customers request connection (channel) and drive bay identifier to be part of 
the symlink name.

On 07/07/2010 04:55 PM, Hannes Reinecke wrote:
>
> SAS devices should be referenced by the SAS address of the target;
> on the initiator side we assume an identity mapping between SAS
> addresses and PCI devnumber.
> SATA devices have an identity mapping between SATA links and
> linux scsi_host structures, so we can map the host number onto
> the SATA link.
> For this to work the LUN numbering needs to be updated, too,
> as SATA devices do not have the concept of a LUN, whereas normal
> SCSI devices have.
>
> Signed-off-by: Hannes Reinecke<hare@suse.de>
>
> diff --git a/extras/path_id/path_id.c b/extras/path_id/path_id.c
> index dcee378..1b6c363 100644
> --- a/extras/path_id/path_id.c
> +++ b/extras/path_id/path_id.c
> @@ -97,7 +97,6 @@ static struct udev_device *handle_scsi_fibre_channel(struct udev_device *parent,
>   	struct udev_device *targetdev;
>   	struct udev_device *fcdev = NULL;
>   	const char *port;
> -	unsigned int lun;
>
>   	targetdev = udev_device_get_parent_with_subsystem_devtype(parent, "scsi", "scsi_target");
>   	if (targetdev = NULL)
> @@ -112,8 +111,7 @@ static struct udev_device *handle_scsi_fibre_channel(struct udev_device *parent,
>   		goto out;
>   	}
>
> -	lun = strtoul(udev_device_get_sysnum(parent), NULL, 10);
> -	path_prepend(path, "fc-%s:0x%04x%04x00000000", port, lun&  0xffff, (lun>>  16)&  0xffff);
> +	path_prepend(path, "fc-%s", port);
>   out:
>   	udev_device_unref(fcdev);
>   	return parent;
> @@ -121,7 +119,34 @@ out:
>
>   static struct udev_device *handle_scsi_sas(struct udev_device *parent, char **path)
>   {
> -	return NULL;
> +	struct udev *udev  = udev_device_get_udev(parent);
> +	struct udev_device *end_dev = NULL;
> +	struct udev_device *sas_dev;
> +	const char *end_dev_wwn;
> +
> +	/* Find end device */
> +	end_dev = parent;
> +	while (1) {
> +		end_dev = udev_device_get_parent(end_dev);
> +		if (end_dev = NULL)
> +			return NULL;
> +		if (!strncmp(udev_device_get_sysname(end_dev), "end_device", 10))
> +			break;
> +	}
> +	if (end_dev = NULL)
> +		return NULL;
> +
> +	/* find sas end device */
> +	sas_dev = udev_device_new_from_subsystem_sysname(udev, "sas_device", udev_device_get_sysname(end_dev));
> +	if (sas_dev = NULL)
> +		return NULL;
> +
> +	end_dev_wwn = udev_device_get_sysattr_value(sas_dev, "sas_address");
> +
> +	path_prepend(path, "sas-%s", end_dev_wwn);
> +
> +	udev_device_unref(sas_dev);
> +	return end_dev;
>   }
>
>   static struct udev_device *handle_scsi_iscsi(struct udev_device *parent, char **path)
> @@ -174,7 +199,7 @@ static struct udev_device *handle_scsi_iscsi(struct udev_device *parent, char **
>   		goto out;
>   	}
>
> -	path_prepend(path, "ip-%s:%s-iscsi-%s-lun-%s", addr, port, target, udev_device_get_sysnum(parent));
> +	path_prepend(path, "ip-%s:%s-iscsi-%s", addr, port, target);
>   out:
>   	udev_device_unref(sessiondev);
>   	udev_device_unref(conndev);
> @@ -183,23 +208,34 @@ out:
>
>   static struct udev_device *handle_scsi_default(struct udev_device *parent, char **path)
>   {
> +	struct udev *udev  = udev_device_get_udev(parent);
>   	struct udev_device *hostdev;
> -	int host, bus, target, lun;
> -	const char *name;
> +	int host, bus, target;
> +	const char *name, *hba, *hostpath;
>   	char *base;
>   	char *pos;
> +	char *type = "scsi";
>   	DIR *dir;
>   	struct dirent *dent;
> -	int basenum;
> -
> -	hostdev = udev_device_get_parent_with_subsystem_devtype(parent, "scsi", "scsi_host");
> -	if (hostdev = NULL)
> -		return NULL;
> +	int basenum, hostnum = 0;
>
>   	name = udev_device_get_sysname(parent);
> -	if (sscanf(name, "%d:%d:%d:%d",&host,&bus,&target,&lun) != 4)
> +	if (sscanf(name, "target%d:%d:%d",&host,&bus,&target) != 3)
>   		return NULL;
>
> +	parent = udev_device_get_parent(parent);
> +	/* Check for libata hosts */
> +	hostdev = udev_device_new_from_subsystem_sysname(udev, "scsi_host", udev_device_get_sysname(parent));
> +	if (hostdev = NULL)
> +		return NULL;
> +	hba = udev_device_get_sysattr_value(hostdev, "proc_name");
> +	if (hba&&  (!strncmp(hba, "sata", 4) || !strcmp(hba, "ahci")))
> +		type = "sata";
> +	if (hba&&  (!strncmp(hba, "pata", 4) || !strncmp(hba, "ata", 3)))
> +		type = "ata";
> +	udev_device_unref(hostdev);
> +	/* Reset to original host path */
> +	hostdev = parent;
>   	/* rebase host offset to get the local relative number */
>   	basenum = -1;
>   	base = strdup(udev_device_get_syspath(hostdev));
> @@ -227,6 +263,7 @@ static struct udev_device *handle_scsi_default(struct udev_device *parent, char
>   		if (strncmp(dent->d_name, "host", 4) != 0)
>   			continue;
>   		i = strtoul(&dent->d_name[4],&rest, 10);
> +		hostnum++;
>   		if (rest[0] != '\0')
>   			continue;
>   		if (basenum = -1 || i<  basenum)
> @@ -239,20 +276,54 @@ static struct udev_device *handle_scsi_default(struct udev_device *parent, char
>   	}
>   	host -= basenum;
>
> -	path_prepend(path, "scsi-%u:%u:%u:%u", host, bus, target, lun);
> +	if (!strcmp(type, "scsi"))
> +		path_prepend(path, "scsi-%u:%u:%u", host, bus, target);
> +	else
> +		path_prepend(path, "%s-%u", type, host);
>   out:
>   	free(base);
>   	return hostdev;
>   }
>
> +static int scsi_is_sata(const char *name)
> +{
> +	char syspath[UTIL_PATH_SIZE];
> +	struct stat stbuf;
> +
> +	strcpy(syspath, name);
> +	strcat(syspath, "/unload_heads");
> +
> +	return (stat(syspath,&stbuf)<  0) ? 0 : 1;
> +}
> +
>   static struct udev_device *handle_scsi(struct udev_device *parent, char **path)
>   {
> +	struct udev *udev  = udev_device_get_udev(parent);
>   	const char *devtype;
>   	const char *name;
>   	const char *id;
>
>   	devtype = udev_device_get_devtype(parent);
> -	if (devtype = NULL || strcmp(devtype, "scsi_device") != 0)
> +	if (devtype = NULL)
> +		return parent;
> +
> +	/* lousy scsi sysfs does not have a "subsystem" for the transport */
> +	name = udev_device_get_syspath(parent);
> +
> +	if (strcmp(devtype, "scsi_device") = 0) {
> +		if (!scsi_is_sata(name)) {
> +			unsigned int host, bus, target, lun;
> +
> +			if (sscanf(udev_device_get_sysname(parent),
> +				   "%d:%d:%d:%d",&host,&bus,&target,&lun) != 4)
> +				return NULL;
> +			path_prepend(path, "lun-0x%04x%04x00000000",
> +				     lun&  0xffff, (lun>>  16)&  0xffff);
> +		}
> +		return parent;
> +	}
> +
> +	if (strcmp(devtype, "scsi_host") = 0)
>   		return parent;
>
>   	/* firewire */
> @@ -263,9 +334,6 @@ static struct udev_device *handle_scsi(struct udev_device *parent, char **path)
>   		goto out;
>   	}
>
> -	/* lousy scsi sysfs does not have a "subsystem" for the transport */
> -	name = udev_device_get_syspath(parent);
> -
>   	if (strstr(name, "/rport-") != NULL) {
>   		parent = handle_scsi_fibre_channel(parent, path);
>   		goto out;
> --
> To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] path_id: Handle SAS and SATA devices

[David Zeuthen]

On Mon, 2010-07-12 at 11:07 +0200, Kay Sievers wrote:
> On Wed, Jul 7, 2010 at 16:55, Hannes Reinecke <hare@suse.de> wrote:
> >
> > SAS devices should be referenced by the SAS address of the target;
> > on the initiator side we assume an identity mapping between SAS
> > addresses and PCI devnumber.
> > SATA devices have an identity mapping between SATA links and
> > linux scsi_host structures, so we can map the host number onto
> > the SATA link.
> > For this to work the LUN numbering needs to be updated, too,
> > as SATA devices do not have the concept of a LUN, whereas normal
> > SCSI devices have.
> 
> David, any chance to give this a try on your SAS box, and see if this
> works as expected for you too?

Sure, will do later this week - it's currently powered off and in a
moving box!

Thanks,
David

Re: [PATCH] path_id: Handle SAS and SATA devices

[David Zeuthen]

Hi,

On Mon, Jul 12, 2010 at 10:47 AM, David Zeuthen <davidz@redhat.com> wrote:
> On Mon, 2010-07-12 at 11:07 +0200, Kay Sievers wrote:
>> On Wed, Jul 7, 2010 at 16:55, Hannes Reinecke <hare@suse.de> wrote:
>> >
>> > SAS devices should be referenced by the SAS address of the target;
>> > on the initiator side we assume an identity mapping between SAS
>> > addresses and PCI devnumber.
>> > SATA devices have an identity mapping between SATA links and
>> > linux scsi_host structures, so we can map the host number onto
>> > the SATA link.
>> > For this to work the LUN numbering needs to be updated, too,
>> > as SATA devices do not have the concept of a LUN, whereas normal
>> > SCSI devices have.
>>
>> David, any chance to give this a try on your SAS box, and see if this
>> works as expected for you too?
>
> Sure, will do later this week - it's currently powered off and in a
> moving box!

OK, I get these additional links in /dev/disk/by-path

+│   ├── pci-0000:06:00.0-sas-0x500000e01b83f362-lun-0x0000000000000000
-> ../../sds
+│   ├── pci-0000:06:00.0-sas-0x500000e01b83f363-lun-0x0000000000000000
-> ../../sdr
+│   ├── pci-0000:06:00.0-sas-0x500000e01b83f442-lun-0x0000000000000000
-> ../../sdq
+│   ├── pci-0000:06:00.0-sas-0x500000e01b83f443-lun-0x0000000000000000
-> ../../sdp
+│   ├── pci-0000:06:00.0-sas-0x500000e01b83f522-lun-0x0000000000000000
-> ../../sdo
+│   ├── pci-0000:06:00.0-sas-0x500000e01b83f523-lun-0x0000000000000000
-> ../../sdn
+│   ├── pci-0000:06:00.0-sas-0x500000e01b843d92-lun-0x0000000000000000
-> ../../sdm
+│   └── pci-0000:06:00.0-sas-0x500000e01b843d93-lun-0x0000000000000000
-> ../../sdl

for four SAS disks with two paths each. Btw, the WWN used is
apparently not that of the actual disk

 # udevadm info -q all -n /dev/sdn|grep ID_WWN E: ID_WWN=0x500000e01b83f520

which matches what is printed on the actual disk

 http://people.freedesktop.org/~david/FUJITSU-MAY2036RC-sas-disk-picture.jpg

however the WWNs that your patch introduces differ from this. However
those WWNs appear here

 # smp_discover /dev/bsg/expander-7\:0 --multiple |grep b83f52
 phy   4:T:attached:[500000e01b83f523:01  t(SSP)]  3 Gbps
 # smp_discover /dev/bsg/expander-7\:1 --multiple |grep b83f52
 phy   4:T:attached:[500000e01b83f522:00  t(SSP)]  3 Gbps

e.g. the WWNs that you use are the WWNs of the actual ports, not the
LUN itself, yes? You should probably use the LUN WWN instead. I mean,
I think people are interested in the WWN of the LUN and they don't
care so much about the WWN of the ports. Or maybe we want both?
Anyway, I *think* that's the way it works but I could be wrong on some
of the SAS details.

FWIW, I've included sg_inq(8) output in [1] for both paths to the disk.

    David

[1] :

# sg_inq /dev/sdo --page 0x83
VPD INQUIRY: Device Identification page
  Designation descriptor number 1, descriptor length: 12
    designator_type: NAA,  code_set: Binary
    associated with the addressed logical unit
      NAA 5, IEEE Company_id: 0xe
      Vendor Specific Identifier: 0x1b83f520
      [0x500000e01b83f520]
  Designation descriptor number 2, descriptor length: 12
    transport: Serial Attached SCSI (SAS)
    designator_type: NAA,  code_set: Binary
    associated with the target port
      NAA 5, IEEE Company_id: 0xe
      Vendor Specific Identifier: 0x1b83f522
      [0x500000e01b83f522]
  Designation descriptor number 3, descriptor length: 8
    transport: Serial Attached SCSI (SAS)
    designator_type: Relative target port,  code_set: Binary
    associated with the target port
      Relative target port: 0x1
  Designation descriptor number 4, descriptor length: 28
    designator_type: SCSI name string,  code_set: UTF-8
    associated with the target device that contains addressed lu
      SCSI name string:
      naa.500000E01B83F520

# sg_inq /dev/sdn --page 0x83
VPD INQUIRY: Device Identification page
  Designation descriptor number 1, descriptor length: 12
    designator_type: NAA,  code_set: Binary
    associated with the addressed logical unit
      NAA 5, IEEE Company_id: 0xe
      Vendor Specific Identifier: 0x1b83f520
      [0x500000e01b83f520]
  Designation descriptor number 2, descriptor length: 12
    transport: Serial Attached SCSI (SAS)
    designator_type: NAA,  code_set: Binary
    associated with the target port
      NAA 5, IEEE Company_id: 0xe
      Vendor Specific Identifier: 0x1b83f523
      [0x500000e01b83f523]
  Designation descriptor number 3, descriptor length: 8
    transport: Serial Attached SCSI (SAS)
    designator_type: Relative target port,  code_set: Binary
    associated with the target port
      Relative target port: 0x2
  Designation descriptor number 4, descriptor length: 28
    designator_type: SCSI name string,  code_set: UTF-8
    associated with the target device that contains addressed lu
      SCSI name string:
      naa.500000E01B83F520

Re: [PATCH] path_id: Handle SAS and SATA devices

[Hannes Reinecke]

David Zeuthen wrote:
> Hi,
> 
> On Mon, Jul 12, 2010 at 10:47 AM, David Zeuthen <davidz@redhat.com> wrote:
>> On Mon, 2010-07-12 at 11:07 +0200, Kay Sievers wrote:
>>> On Wed, Jul 7, 2010 at 16:55, Hannes Reinecke <hare@suse.de> wrote:
>>>> SAS devices should be referenced by the SAS address of the target;
>>>> on the initiator side we assume an identity mapping between SAS
>>>> addresses and PCI devnumber.
>>>> SATA devices have an identity mapping between SATA links and
>>>> linux scsi_host structures, so we can map the host number onto
>>>> the SATA link.
>>>> For this to work the LUN numbering needs to be updated, too,
>>>> as SATA devices do not have the concept of a LUN, whereas normal
>>>> SCSI devices have.
>>> David, any chance to give this a try on your SAS box, and see if this
>>> works as expected for you too?
>> Sure, will do later this week - it's currently powered off and in a
>> moving box!
> 
> OK, I get these additional links in /dev/disk/by-path
> 
> +│   ├── pci-0000:06:00.0-sas-0x500000e01b83f362-lun-0x0000000000000000
> -> ../../sds
> +│   ├── pci-0000:06:00.0-sas-0x500000e01b83f363-lun-0x0000000000000000
> -> ../../sdr
> +│   ├── pci-0000:06:00.0-sas-0x500000e01b83f442-lun-0x0000000000000000
> -> ../../sdq
> +│   ├── pci-0000:06:00.0-sas-0x500000e01b83f443-lun-0x0000000000000000
> -> ../../sdp
> +│   ├── pci-0000:06:00.0-sas-0x500000e01b83f522-lun-0x0000000000000000
> -> ../../sdo
> +│   ├── pci-0000:06:00.0-sas-0x500000e01b83f523-lun-0x0000000000000000
> -> ../../sdn
> +│   ├── pci-0000:06:00.0-sas-0x500000e01b843d92-lun-0x0000000000000000
> -> ../../sdm
> +│   └── pci-0000:06:00.0-sas-0x500000e01b843d93-lun-0x0000000000000000
> -> ../../sdl
> 
> for four SAS disks with two paths each. Btw, the WWN used is
> apparently not that of the actual disk
> 
>  # udevadm info -q all -n /dev/sdn|grep ID_WWN>  E: ID_WWN=0x500000e01b83f520
> 
> which matches what is printed on the actual disk
> 
>  http://people.freedesktop.org/~david/FUJITSU-MAY2036RC-sas-disk-picture.jpg
> 
> however the WWNs that your patch introduces differ from this. However
> those WWNs appear here
> 
>  # smp_discover /dev/bsg/expander-7\:0 --multiple |grep b83f52
>  phy   4:T:attached:[500000e01b83f523:01  t(SSP)]  3 Gbps
>  # smp_discover /dev/bsg/expander-7\:1 --multiple |grep b83f52
>  phy   4:T:attached:[500000e01b83f522:00  t(SSP)]  3 Gbps
> 
> e.g. the WWNs that you use are the WWNs of the actual ports, not the
> LUN itself, yes? You should probably use the LUN WWN instead. I mean,
> I think people are interested in the WWN of the LUN and they don't
> care so much about the WWN of the ports. Or maybe we want both?
> Anyway, I *think* that's the way it works but I could be wrong on some
> of the SAS details.
> 
No, that was _exactly_ my intention.
'by-path' is the physical path, ie the path is identified by the physical
properties. Hence we need to refer to the SAS port WWN here.
The WWN of the disk is referred to in 'by-id'.

So the path_id program is working as expected from my POV.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		      zSeries & Storage
hare@suse.de			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Markus Rex, HRB 16746 (AG Nürnberg)

Re: [PATCH] path_id: Handle SAS and SATA devices

[David Zeuthen]

Hey Hannes,

On Thu, Aug 5, 2010 at 3:37 AM, Hannes Reinecke <hare@suse.de> wrote:
> No, that was _exactly_ my intention.

Would be useful with tree /dev/disk/by-path output in the commit message.

> 'by-path' is the physical path, ie the path is identified by the physical
> properties. Hence we need to refer to the SAS port WWN here.
> The WWN of the disk is referred to in 'by-id'.
>
> So the path_id program is working as expected from my POV.

But how is the symlink

 /dev/disk/by-path/pci-0000:06:00.0-sas-0x500000e01b83f523-lun-0x0000000000000000
-> ../../sdn

in any way actually useful? I mean, this link refers to the 2nd port
of the first LUN of some SAS device that is connected to some HBA
connected via PCI. I can't really see how it has anything to do with
the actual _path_ to do the disk. E.g. if I move the disk to another
PHY on the SAS expander then that link will point to that. So it's not
really by path. If anything, it's by-id.

Btw, exactly what problem are you trying to solve with this patch?
Wouldn't it be better to, say, just use SES identifiers e.g. something
like this

 /dev/disk/by-path/sas-enclosure-Promise_VTrak_J310sD-0x5001234-serial-abcd-slot05

that actually tells the user that this link refers to slot 5 of an
enclosure of the given make/model, with a WWN of 0x5001234 and serial
number abcd. I think long-term we really want something like that....
all it requires is a bit of programming.

(OK, so the proposed sas-enclosure- path is "local" to the enclosure
but I think that's OK - it's normally not really useful nor
interesting _where_ that particular enclosure really is - what's
interesting is that it's easy to identify slots in enclosures.)

    David

Re: [PATCH] path_id: Handle SAS and SATA devices

[Hannes Reinecke]

David Zeuthen wrote:
> Hey Hannes,
> 
> On Thu, Aug 5, 2010 at 3:37 AM, Hannes Reinecke <hare@suse.de> wrote:
>> No, that was _exactly_ my intention.
> 
> Would be useful with tree /dev/disk/by-path output in the commit message.
> 
>> 'by-path' is the physical path, ie the path is identified by the physical
>> properties. Hence we need to refer to the SAS port WWN here.
>> The WWN of the disk is referred to in 'by-id'.
>>
>> So the path_id program is working as expected from my POV.
> 
> But how is the symlink
> 
>  /dev/disk/by-path/pci-0000:06:00.0-sas-0x500000e01b83f523-lun-0x0000000000000000
> -> ../../sdn
> 
> in any way actually useful? I mean, this link refers to the 2nd port
> of the first LUN of some SAS device that is connected to some HBA
> connected via PCI. I can't really see how it has anything to do with
> the actual _path_ to do the disk. E.g. if I move the disk to another
> PHY on the SAS expander then that link will point to that. So it's not
> really by path. If anything, it's by-id.
> 
Yeah, I've discussed the same thing with Kay.
You are right, referencing the SAS WWN of the remote port is
pointless. We should rather reference the phy-number of the local
port this device is connected to; that we'll be getting a 'real'
path-id for SAS.
Guess I have to redo that thing.

> Btw, exactly what problem are you trying to solve with this patch?
> Wouldn't it be better to, say, just use SES identifiers e.g. something
> like this
> 
>  /dev/disk/by-path/sas-enclosure-Promise_VTrak_J310sD-0x5001234-serial-abcd-slot05
> 
> that actually tells the user that this link refers to slot 5 of an
> enclosure of the given make/model, with a WWN of 0x5001234 and serial
> number abcd. I think long-term we really want something like that....
> all it requires is a bit of programming.
> 
Why, of course. But that would be 'by-id' again, as it's just referring
to the disk, not how to get there.

The idea of the 'by-path' thing is that it should describe the path
(or, in SCSI speak, the ITL Nexus) of how we access the device.
So in principle you should be able to exchange the backing device
at that point but the link would stay the same.

As for the SES identifier: in principle yes.
Only we have this darned restriction of working within the
limits of the named device _only_.
And as SES is in general handled via a different device
we'd have a hard time getting information from there.

We've been stuck with the same problem for SCSI tapes
due to the use of 'st' and 'nst' devices, but finally
got it solved via bsg. Maybe we can pull a similar trick
here, but I'm not sure.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		      zSeries & Storage
hare@suse.de			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Markus Rex, HRB 16746 (AG Nürnberg)

Re: [PATCH] path_id: Handle SAS and SATA devices

[David Zeuthen]

Hey,

On Thu, Aug 5, 2010 at 9:35 AM, Hannes Reinecke <hare@suse.de> wrote:
>> But how is the symlink
>>
>>  /dev/disk/by-path/pci-0000:06:00.0-sas-0x500000e01b83f523-lun-0x0000000000000000
>> -> ../../sdn
>>
>> in any way actually useful? I mean, this link refers to the 2nd port
>> of the first LUN of some SAS device that is connected to some HBA
>> connected via PCI. I can't really see how it has anything to do with
>> the actual _path_ to do the disk. E.g. if I move the disk to another
>> PHY on the SAS expander then that link will point to that. So it's not
>> really by path. If anything, it's by-id.
>>
> Yeah, I've discussed the same thing with Kay.
> You are right, referencing the SAS WWN of the remote port is
> pointless. We should rather reference the phy-number of the local
> port this device is connected to; that we'll be getting a 'real'
> path-id for SAS.
> Guess I have to redo that thing.

That sounds good - would be nice to include the word expander in the
link name so it's easy to figure out what the link is really about.

Also remember that SAS enclosures can be nested - in fact, in many
setups people nest enclosures like this

 HBA1 <-> expander1 <-> expander2 <-> expander3

Now, for a disk connected to PHY 5 of expander 1, I'd expect the name
to be like this

 /dev/disk/by-path/pci-0000:06:00.0-sas-expander-0x500000e1-phy05

but what about a disk connected to PHY 6 of expander 2 (with expander
2 being connected to PHYs 10-13 through a wide port)? Would it be

 /dev/disk/by-path/pci-0000:06:00.0-sas-expander-0x500000e2-phy06

or

 /dev/disk/by-path/pci-0000:06:00.0-sas-expander-0x500000e1-phy10,11,12,13-sas-expander-0x500000e2-phy06

My take is that the latter is the "correct" answer but I also think
it's pretty useless (kinda like the sysfs hierarchy is super deep)....
at the same time I think the former is what 99.9% of people expects
and wants [1]. Thoughts?

> And as SES is in general handled via a different device
> we'd have a hard time getting information from there.

Right, the enclosure services device is a separate SCSI device. But
James actually already wrote a driver for such devices and it sets up
symlinks in sysfs that can be used to easily name the devices here in
user space.

     David