Bug 553292

Event posted on 01-06-2010 03:03pm EST by woodard


This forks off of IT 364360.
This event sent from IssueTracker by kbaxley  [LLNL (HPC)]
 issue 381858

Event posted on 01-06-2010 03:20pm EST by kbaxley

This ticket points out some issues that LLNL ran into with the RHEL5
version of path_id from udev.  This was discovered while the lab was
trying to sort out some other problems with path_id on RHEL6.

Here's some history behind it:

Recap of problem:  On RHEL6 A2, /dev/disk/by-path was not being populated
for our
jbods (several different configs, all SATA disks behind LSI Logic
SAS1068E
based SAS controllers with expanders).  LLNL narrowed it down to the
/lib/udev/path_id executable.

These are the args being passed to path_id by udev on LLNL's test box:

/devices/pci0000:00/0000:00:05.0/host0/target0:0:0/0:0:0:0/block/sda
/devices/pci0000:00/0000:00:0f.0/0000:07:00.0/host8/port-8:0/expander-8:0/port-8:0:1/end_device-8:0:1/target8:0:0/8:0:0:0/block/sdb
/devices/pci0000:00/0000:00:0f.0/0000:07:00.0/host8/port-8:0/expander-8:0/port-8:0:11/end_device-8:0:11/target8:0:10/8:0:10:0/block/sdl
/devices/pci0000:00/0000:00:0f.0/0000:07:00.0/host8/port-8:0/expander-8:0/port-8:0:10/end_device-8:0:10/target8:0:9/8:0:9:0/block/sdk
/devices/pci0000:00/0000:00:0f.0/0000:07:00.0/host8/port-8:0/expander-8:0/port-8:0:13/end_device-8:0:13/target8:0:12/8:0:12:0/block/sdn
/devices/pci0000:00/0000:00:02.0/usb2/2-7/2-7.1/2-7.1:1.0/input/input3/event3
/devices/pci0000:00/0000:00:0f.0/0000:07:00.0/host8/port-8:0/expander-8:0/port-8:0:12/end_device-8:0:12/target8:0:11/8:0:11:0/block/sdm
/devices/pci0000:00/0000:00:0f.0/0000:07:00.0/host8/port-8:0/expander-8:0/port-8:0:15/end_device-8:0:15/target8:0:14/8:0:14:0/block/sdp
/devices/pci0000:00/0000:00:0f.0/0000:07:00.0/host8/port-8:0/expander-8:0/port-8:0:16/end_device-8:0:16/target8:0:15/8:0:15:0/block/sdq
/devices/pci0000:00/0000:00:0f.0/0000:07:00.0/host8/port-8:0/expander-8:0/port-8:0:14/end_device-8:0:14/target8:0:13/8:0:13:0/block/sdo
/devices/pci0000:00/0000:00:0f.0/0000:07:00.0/host8/port-8:0/expander-8:0/port-8:0:2/end_device-8:0:2/target8:0:1/8:0:1:0/block/sdc
/devices/pci0000:00/0000:00:0f.0/0000:07:00.0/host8/port-8:0/expander-8:0/port-8:0:6/end_device-8:0:6/target8:0:5/8:0:5:0/block/sdg
/devices/pci0000:00/0000:00:02.0/usb2/2-7/2-7.1/2-7.1:1.1/input/input4/event4
/devices/pci0000:00/0000:00:0f.0/0000:07:00.0/host8/port-8:0/expander-8:0/port-8:0:5/end_device-8:0:5/target8:0:4/8:0:4:0/block/sdf
/devices/pci0000:00/0000:00:0f.0/0000:07:00.0/host8/port-8:0/expander-8:0/port-8:0:3/end_device-8:0:3/target8:0:2/8:0:2:0/block/sdd
/devices/pci0000:00/0000:00:0f.0/0000:07:00.0/host8/port-8:0/expander-8:0/port-8:0:7/end_device-8:0:7/target8:0:6/8:0:6:0/block/sdh
/devices/pci0000:00/0000:00:0f.0/0000:07:00.0/host8/port-8:0/expander-8:0/port-8:0:4/end_device-8:0:4/target8:0:3/8:0:3:0/block/sde
/devices/pci0000:00/0000:00:0f.0/0000:07:00.0/host8/port-8:0/expander-8:0/port-8:0:8/end_device-8:0:8/target8:0:7/8:0:7:0/block/sdi
/devices/pci0000:00/0000:00:0f.0/0000:07:00.0/host8/port-8:0/expander-8:0/port-8:0:9/end_device-8:0:9/target8:0:8/8:0:8:0/block/sdj
/devices/pci0000:00/0000:00:06.1/sound/card0/controlC0
/devices/pci0000:00/0000:00:06.1/sound/card0/controlC0

sda is a lone SATA disk on the on-board SATA controller, while sdb thru
sdq are the SATA disks on the jbod.

Running sda and sdb manually:

# path_id
/devices/pci0000:00/0000:00:05.0/host0/target0:0:0/0:0:0:0/block/sda
ID_PATH=pci-0000:00:05.0-scsi-0:0:0:0
# path_id
/devices/pci0000:00/0000:00:0f.0/0000:07:00.0/host8/port-8:0/expander-8:0/port-8:0:1/end_device-8:0:1/target8:0:0/8:0:0:0/block/sdb
# echo $?
1

**Here's where RHEL5 comes in**

The customer then tried using an older version of path_id from RHEL5 to
see if it would help.

Copying path_id from rhel5 (udev-095-14.20.el5_3) over /lib/udev/path_id
and rerunning /sbin/start_udev, /dev/disk/by-path seems correctly
populated:

ls -l /dev/disk/by-path
total 0
lrwxrwxrwx 1 root root  9 2010-01-05 14:54 pci-0000:00:05.0-scsi-0:0:0:0
-> ../../sda
lrwxrwxrwx 1 root root 10 2010-01-05 14:54
pci-0000:00:05.0-scsi-0:0:0:0-part1 -> ../../sda1
lrwxrwxrwx 1 root root 10 2010-01-05 14:54
pci-0000:00:05.0-scsi-0:0:0:0-part2 -> ../../sda2
lrwxrwxrwx 1 root root  9 2010-01-05 15:42
pci-0000:07:00.0-sas-0x500605b000eb1710:1:0-0x50030480002595c8:8 ->
../../sdb
lrwxrwxrwx 1 root root  9 2010-01-05 15:42
pci-0000:07:00.0-sas-0x500605b000eb1710:1:0-0x50030480002595c9:9 ->
../../sdc
lrwxrwxrwx 1 root root  9 2010-01-05 15:42
pci-0000:07:00.0-sas-0x500605b000eb1710:1:0-0x50030480002595ca:10 ->
../../sdd
lrwxrwxrwx 1 root root  9 2010-01-05 15:42
pci-0000:07:00.0-sas-0x500605b000eb1710:1:0-0x50030480002595cb:11 ->
../../sde
lrwxrwxrwx 1 root root  9 2010-01-05 15:42
pci-0000:07:00.0-sas-0x500605b000eb1710:1:0-0x50030480002595cc:12 ->
../../sdf
lrwxrwxrwx 1 root root  9 2010-01-05 15:42
pci-0000:07:00.0-sas-0x500605b000eb1710:1:0-0x50030480002595cd:13 ->
../../sdg
lrwxrwxrwx 1 root root  9 2010-01-05 15:42
pci-0000:07:00.0-sas-0x500605b000eb1710:1:0-0x50030480002595ce:14 ->
../../sdh
lrwxrwxrwx 1 root root  9 2010-01-05 15:42
pci-0000:07:00.0-sas-0x500605b000eb1710:1:0-0x50030480002595cf:15 ->
../../sdi
lrwxrwxrwx 1 root root  9 2010-01-05 15:42
pci-0000:07:00.0-sas-0x500605b000eb1710:1:0-0x50030480002595d0:16 ->
../../sdj
lrwxrwxrwx 1 root root  9 2010-01-05 15:42
pci-0000:07:00.0-sas-0x500605b000eb1710:1:0-0x50030480002595d1:17 ->
../../sdk
lrwxrwxrwx 1 root root  9 2010-01-05 15:42
pci-0000:07:00.0-sas-0x500605b000eb1710:1:0-0x50030480002595d2:18 ->
../../sdl
lrwxrwxrwx 1 root root  9 2010-01-05 15:42
pci-0000:07:00.0-sas-0x500605b000eb1710:1:0-0x50030480002595d3:19 ->
../../sdm
lrwxrwxrwx 1 root root  9 2010-01-05 15:42
pci-0000:07:00.0-sas-0x500605b000eb1710:1:0-0x50030480002595d4:20 ->
../../sdn
lrwxrwxrwx 1 root root  9 2010-01-05 15:42
pci-0000:07:00.0-sas-0x500605b000eb1710:1:0-0x50030480002595d5:21 ->
../../sdo
lrwxrwxrwx 1 root root  9 2010-01-05 15:42
pci-0000:07:00.0-sas-0x500605b000eb1710:1:0-0x50030480002595d6:22 ->
../../sdp
lrwxrwxrwx 1 root root  9 2010-01-05 15:42
pci-0000:07:00.0-sas-0x500605b000eb1710:1:0-0x50030480002595d7:23 ->
../../sdq

Running sda and sdb manually with the rhel5 path_id:

# ./path_id
/devices/pci0000:00/0000:00:05.0/host0/target0:0:0/0:0:0:0/block/sda
./path_id: line 441: cd:
/sys/devices/pci0000:00/0000:00:05.0/host0/target0:0:0/0:0:0:0/block/subsystem:
No such file or directory
./path_id: line 73: [: [0-9]*: integer expression expected
./path_id: line 223: 0/target0:0:0 - 0/target0:0:0: division by 0 (error
token is ":0:0 - 0/target0:0:0")
# ./path_id
/devices/pci0000:00/0000:00:0f.0/0000:07:00.0/host8/port-8:0/expander-8:0/port-8:0:1/end_device-8:0:1/target8:0:0/8:0:0:0/block/sdb
./path_id: line 441: cd:
/sys/devices/pci0000:00/0000:00:0f.0/0000:07:00.0/host8/port-8:0/expander-8:0/port-8:0:1/end_device-8:0:1/target8:0:0/8:0:0:0/block/subsystem:
No such file or directory
ID_PATH=pci-0000:07:00.0-sas-0x500605b000eb1710:1:0-0x50030480002595c8:8

So the jbod drives are seemingly handled OK and the on-board one isn't
(although what appears to be the correct link appears in by-path).


So the RHEL5 path_id works (with errors) but the customer is not sure why
(I wouldn't conclude that it works simply because it ignores the errors
since it doesn't produce a result when they run it manually that udev
would be able to use.  So that's unexplained.)


This event sent from IssueTracker by kbaxley  [LLNL (HPC)]
 issue 381858

Event posted on 03-02-2010 02:41pm EST by woodard

	From: 	Jim Garlick <garlick>
	Subject: 	Re: udev problem
	Date: 	March 2, 2010 1:36:21 PM CST
	To: 	Ben Coyote Woodard <bwoodard>
	Cc: 	Brian Behlendorf <behlendorf1>

On Tue, Mar 02, 2010 at 01:25:05PM -0600, Ben Woodard wrote:

On Mar 2, 2010, at 10:45 AM, Jim Garlick wrote:
I think Brian decided that mptsas was not to blame for his issues, it
was udev. I need to find out where we are with that this week also.
At one point I rolled a patch that fixed the persistent device naming
for us but it may still not be quite right for upstream.  Did I file that
with you?  

I had one from you with regards to path_id from you. Is that the same
one?

We should get that fixed for the B1 I would think if we can...

It may be too late for B1 at this point but we can try. Give me what you
have and I'll get working on it.

Right, path_id is the problem.

Here is the patch I am applying to udev-147-2.fc13.src.rpm
which works for our setup.  Hopefully I commented in more detail and
that wound up in your bug?  It seems like I had decided that this
needed more work.

Anyway, I'm not necessarily hung up on B1 but since persistent device
naming for SAS devices is broken for all configurations, I should think
would be a high priority for RH to get working.  Also, this is in some
sense a regression because the old crappy shell script that was there
before did work for some configurations (ours for example).

Jim
_____________________


diff -ur udev-147.orig/extras/path_id/path_id.c
udev-147/extras/path_id/path_id.c
--- udev-147.orig/extras/path_id/path_id.c	2010-01-11 11:41:26.174880808
-0800
+++ udev-147/extras/path_id/path_id.c	2010-01-11 15:47:29.832956149 -0800
@@ -121,7 +121,47 @@

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;
+	struct udev_device *sasdev;
+	char syspath[UTIL_PATH_SIZE], *base;
+	const char *name, *enc, *bay;
+
+	end_dev = parent;
+	while (1) {
+		end_dev = udev_device_get_parent(end_dev);
+		if (end_dev == NULL)
+			return NULL;
+		name = udev_device_get_sysname(end_dev);
+		if (strstr(name, "end_device-"))
+			break;
+	}
+	base = strdup(udev_device_get_syspath(end_dev));
+	if (!base)
+		return NULL;
+	snprintf(syspath, sizeof(syspath), "%s/sas_device/%s", base, name);
+	free(base);
+
+	sasdev = udev_device_new_from_syspath(udev, syspath);
+	if (sasdev == NULL) {
+		fprintf(stderr, "unable to access '%s'\n", syspath);
+		return NULL;
+	}
+	enc = udev_device_get_sysattr_value(sasdev, "enclosure_identifier");
+	if (enc == NULL) {
+		parent = NULL;
+		goto out;
+	}
+	bay = udev_device_get_sysattr_value(sasdev, "bay_identifier");
+	if (bay == NULL) {
+		parent = NULL;
+		goto out;
+	}
+
+	path_prepend(path, "sas-%s-%s", enc, bay);
+out:
+	udev_device_unref(sasdev);
+	return parent;
}

static struct udev_device *handle_scsi_iscsi(struct udev_device *parent,
char **path)


This event sent from IssueTracker by kbaxley 
 issue 381858

Event posted on 03-02-2010 03:23pm EST by kbaxley

Customer saw the same problem in udev on RHEL6 (which was what the B1
comments were all about).

They would also like to see this fixed in RHEL5, since it appears to be
broken there as well.

They're viewing this as a regression, so, we need to get some attention
on it.

Thanks.


This event sent from IssueTracker by kbaxley 
 issue 381858

Development Management has reviewed and declined this request.  You may appeal
this decision by reopening this request.