Hey Hannes,
On Thu, Aug 5, 2010 at 3:37 AM, Hannes Reinecke <hare@xxxxxxx> 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
--
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
