[systemd-devel] [PATCH] udevd: SAS: use SAS addr + PHY id in by-path whenever possible.

[Michal Sekletar]

On Tue, Sep 23, 2014 at 01:11:54PM -0400, Kay Sievers wrote:
> ----- Original Message -----
> > On Tue, Sep 23, 2014 at 12:33:54PM +0200, Maurizio Lombardi wrote:
> > > 
> > > On Mon, 2014-09-22 at 16:58 +0200, Tom Gundersen wrote:
> > > > Hi Maurizio,
> > > > 
> > > > On Mon, Sep 22, 2014 at 11:48 AM, Maurizio Lombardi <mlombard at redhat.com>
> > > > wrote:
> > > > > This patch changes the naming scheme for sas disks. The original names
> > > > > used
> > > > > disk's sas address and lun, the new scheme uses sas address of the
> > > > > nearest expander (if available) and a phy id of the used connection.
> > > > > If no expander is used, the phy id of hba phy is used.
> > > > > Note that names that refer to RAID or other abstract devices are
> > > > > unchanged.
> > > > 
> > > > What's the problem with the current scheme, what's the benefit of the
> > > > new one? Will this break backwards compatibility, if so, why is this
> > > > justifiable?
> > > 
> > > Suppose you have the following configuration:
> > > 
> > > pci card --> SAS expander --> hard drive
> > > 
> > > you can think to an expander as a box with N slots, each slot can be
> > > connected to 1 hard drive.
> > > 
> > > The problem with the current scheme is that it uses the SAS addr of the
> > > hard drives in by-path names and this is not sufficient to identify its
> > > physical
> > > position, which is what by-path is supposed to do.
> > > 
> > > Example:
> > > 
> > > If we add an hard disk to the SAS expander, what will we find in by-path?
> > > 
> > > ------------
> > > Current scheme:
> > > pci-0000:1c:00.0-sas-0x5000c5001ac1031a-lun-0 -> ../../sdc
> > > 
> > > New scheme:
> > > pci-0000:1c:00.0-sas-exp0x5003048000201dff-phy2-lun-0 -> ../../sdc
> > > ------------
> > > 
> > > Now, what happens if we move the drive to a different slot?
> > > 
> > > ------------
> > > Current scheme:
> > > pci-0000:1c:00.0-sas-0x5000c5001ac1031a-lun-0 -> ../../sdc
> > > 
> > > New scheme:
> > > pci-0000:1c:00.0-sas-exp0x5003048000201dff-phy4-lun-0 -> ../../sdc
> > > ------------
> > > 
> > > As you can see, with the current scheme by-path is not functioning as
> > > intended because
> > > it does not show the change of the physical position of the drive.
> > > 
> > > So, it would be better to use the SAS addr of the nearest expander plus the
> > > PHY id the disk is connected to;
> > > this way, when you move the drive, the change will be reflected in the
> > > by-path
> > > link, as shown in the example before.
> > > 
> > > Note: it is not always possible get the PHY id the drive is connected to
> > > (it happens when SAS wide ports are used);
> > > in this case, we'll keep the old by-path format.
> > 
> > Patch looks OK. I think we should apply it. It's unfortunate that it
> > breaks the naming with previous releases, but it seems better to break
> > it now than to continue with the existing insufficient mechanism.
> 
> We are not applying this patch now. It introduces a complete new
> scheme and we do not want to extend the current SCSI code, we only
> fix obvious bugs.

Fine with me, however not sure what our story should be for years to come
regarding SCSI stuff downstream. Kay, any serious objections to applying only
downstream for RHEL?

Michal
> 
> This is very specific SCSI stuff and it should move out of the
> udev/systemd code base. None of us has the slightest idea how it
> works, we cannot review or maintain it, we do not know what's
> the right thing to do.
> 
> Someone with a storage background and willing to maintain the code,
> please start to move this code to some other package. Hannes Reinecke
> already moved parts of the scsi_id tool to the sg3_utils package.
> scsi_id along with the SCSI code in path_id will be removed from
> systemd/udev when sg3_util, or any other package, has taken over the
> functionality.
> 
> Thanks,
> Kay
> _______________________________________________
> systemd-devel mailing list
> systemd-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel