David Zeuthen wrote: > 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. > Yeah, I've discussed the same thing with Kay. You are right, referencing the SAS WWN of the remote port is pointless. We should rather reference the phy-number of the local port this device is connected to; that we'll be getting a 'real' path-id for SAS. Guess I have to redo that thing. > 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. > Why, of course. But that would be 'by-id' again, as it's just referring to the disk, not how to get there. The idea of the 'by-path' thing is that it should describe the path (or, in SCSI speak, the ITL Nexus) of how we access the device. So in principle you should be able to exchange the backing device at that point but the link would stay the same. As for the SES identifier: in principle yes. Only we have this darned restriction of working within the limits of the named device _only_. And as SES is in general handled via a different device we'd have a hard time getting information from there. We've been stuck with the same problem for SCSI tapes due to the use of 'st' and 'nst' devices, but finally got it solved via bsg. Maybe we can pull a similar trick here, but I'm not sure. Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage hare@xxxxxxx +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Markus Rex, 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
