Hi Christophe - On Wed, Oct 05, 2005 at 11:27:38PM +0200, Christophe Varoqui wrote: > > > I haven't recently looked at dm or dm multipath naming, but dm and dm > > multipath should not have a different naming scheme outside of udev. > > > Do you mean we should stop naming the maps after aliases ? > If so, there are quite a few glitches ahead : the multipath configurator > and daemon will have a hard time playing with those meaningful aliases. > > They are used for : > 1) printing meaningful map names (multipath -l, multipathd -k"show > maps") > 2) limiting the scope (multipath -l mymap, multipathd -k"del map mymap") > 3) naming /dev/mapper/ nodes > > > I'm all in favor of keeping the naming policies in a central place > (udev). But can we safely lose (1) and (2) ? Sorry, I am not up to date on current dm or dm multipath so I can't answer those. But readable persistent naming should be done in udev and be the same for all devices. > Can/will this "outlaw" behaviour persist ? Yes, as long as no one patches/fixes it :) > > udev now has persistent naming, and probably could or should have a dm_id > > (dm_id could run scsi_id on a single path, unless dm is passing down scsi > > ioctl's). The udev persistent naming scheme is not intuitive (i.e. not > > easy for people to create and use). > > > Are you sure you mean persistent like "stable enumeration accross > reboots, and even accross a cluster", or simply persistent like > "predictable" ? udev does not generate enumerations for its solution. It does have both persistent as in predictable naming (by-path), based on some *kernel* enumerations (i.e. sysfs paths), like scsi host number, and I think some pci slot numbers and probably more. Plus it has names that are ummmmm persistent (by-id). > Personnaly, I fail to see how to achieve persistance through udev (1st > definition, the one PatrickC cares about). Do I miss something ? Yes ... it can name (or create sym links) based on the execution of device (or in sysfs terms bus) specific programs. There now exist a scsi_id, ata_id and more under udev/extras. > That said, I agree it makes sense : a persistent (and reliable) > enumeration naming through a udev '%e'-like substitution would be a nice > and simple thing to use. No, udev enumeration is not persistent, and Kay never (AFAIR) could come up with a fast and simple way to guarantee that the enumeration was atomic. > > Intuitive names could be built upon the persistent names as part of udev, > > like an alias, or if you could "match" a NAME, and have a new udev rule > > like: > > > > NAME=="disk/by-id/foo" SYMLINK+="disk/by-simple/my-database" > > > I fail to see how this can be done without 1 rule per multipath. Right, I assumed this was required no matter what the solution, I don't see how you can have readable and persistent /dev names covering all possible disks without some one-to-one mapping. > Administrative scalability was the purpose of PatrickC's patch, ie no > admin-supplied aliases. Guess I need to actually read and understand the patch :-/ Here is some /dev, lsscsi and scsi_id output on a SLES9 system (rpm udev-021-36.55). by-path is basically pci and scsi bus_id's; by-id is basically scsi_id plus partition output. [Uh oh, the by-path output looks broken! It should be scsi-1:0:0:0 pointing to sdc not scsi-0:0:0:0, but this shows the /dev structure.] I hope this clears things up: elm3a47:~ # ls -l /dev/disk/by-path | grep sdc lrwxrwxrwx 1 root root 9 Oct 5 08:18 pci-0000:01:01.1-scsi-0:0:0:0 -> ../../sdc lrwxrwxrwx 1 root root 10 Oct 5 08:18 pci-0000:01:01.1-scsi-0:0:0:0p1 -> ../../sdc1 lrwxrwxrwx 1 root root 10 Oct 5 08:18 pci-0000:01:01.1-scsi-0:0:0:0p2 -> ../../sdc2 lrwxrwxrwx 1 root root 10 Oct 5 08:18 pci-0000:01:01.1-scsi-0:0:0:0p3 -> ../../sdc3 elm3a47:~ # ls -l /dev/disk/by-id | grep sdc lrwxrwxrwx 1 root root 9 Oct 5 08:18 320000004cf311121 -> ../../sdc lrwxrwxrwx 1 root root 10 Oct 5 08:18 320000004cf311121p1 -> ../../sdc1 lrwxrwxrwx 1 root root 10 Oct 5 08:18 320000004cf311121p2 -> ../../sdc2 lrwxrwxrwx 1 root root 10 Oct 5 08:18 320000004cf311121p3 -> ../../sdc3 elm3a47:~ # lsscsi | grep sdc [1:0:0:0] disk IBM-ESXS ST318453FC F B953 /dev/sdc elm3a47:~ # ls -l /sys/block/sdc/device lrwxrwxrwx 1 root root 0 Oct 5 08:18 /sys/block/sdc/device -> ../../devices/pci0000:00/0000:00:1f.0/0000:01:01.1/host1/1:0:0:0 elm3a47:~ # scsi_id -g -s /block/sdc 320000004cf311121 -- Patrick Mansfield -- dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
