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