On 03/30/2012 09:59 AM, Nils Carlson wrote:
> Hi,
>
> We recently upgraded our version of udev and I saw that the symlinks
> under /dev/disk/by-path/ have changed since udev started using the
> path_id C code to no longer include phy enumeration for SAS disks.
> Was this change intentional? Would anyone mind if i re-create the
> behavior of the old bash script as we were using it?
>
Not everybody at once ... I've just had several customer calls for
exactly the same issue.
Actually ... the company name seems to be vaguely familiar ...
To quote myself:
> Problem is that SAS has something called 'wide-ports', ie inherent
> port-bonding for SAS. When a system has wide ports, several PHYs
> are merged _physically_ together into a single connector.
> However, on the system side we're only seeing PHYs, so it'
> impossible to tell which of the phy has been used.
>
> So to handle this correctly we would need to generate symlinks for
> each phy in a wide port; however, currently the path_id program is
> only capable of printing out _one_ link per wide port.
>
> And actually, the original path_id script also printed out only
> one symlink, so even there it didn't handle wide ports correctly.
>
I've discussed this issue with Kay Sievers, and we agreed that we
should be fixing this.
It should be relatively easy to update the path_id program to print
out a link for each phy in a wide-port, and then we could do a
static enumeration via udev rules like
$env{ID_SAS_PHY0}=="?*", SYMLINK+="/dev/disk/by-path/$ID_SAS_PHY0"
$env{ID_SAS_PHY1}=="?*", SYMLINK+="/dev/disk/by-path/$ID_SAS_PHY1"
seeing that there is currently a max of 8 phys per wide port, we
only would need to specify 8 lines here. Which should be too bad.
You're welcome to lend a hand ...
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries & Storage
hare@xxxxxxx +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
