persistent readable names

This patch is more for discussion than inclusion at the moment. Basically it's unrealistic for users with hundreds of disks to alias them all in /etc/multipath.conf and the default names are very unwieldy.

What this patch does is attach a name to any un-aliased path and write that name to /etc/multipath.names. The file is read again every time the paths are added so they are persistent.

There are a small number of possibly contentious things:
- the multipath.names file is in a different format from the config file. It's easier to parse this one and it's not meant to be human editable really. Also extending the existing parser to cope with the ability to read bits for the same MPE from more than one place looked hard :)

- The names file is held in /etc which may not be available if multipath is run from an initrd - though it does fail silently if it can't be written.

The feature is selected with

defaults {
autonames 1
}

in the config file, and the names can be formatted with

defaults {
autoname_prefix "multipath%d"
}

patrick

diff -rwup multipath-tools-0.4.5/libmultipath/config.c multipath-tools-0.4.5.new/libmultipath/config.c
@@ -330,6 +330,9 @@ free_config (struct config * conf)
 	if (conf->default_hwhandler)
 		FREE(conf->default_hwhandler);
 
+	if (conf->autoname_prefix)
+		FREE(conf->autoname_prefix);
+
 	free_blacklist(conf->blist);
 	free_mptable(conf->mptable);
 	free_hwtable(conf->hwtable);

@@ -407,6 +410,9 @@ load_config (char * file)
 	if (conf->default_hwhandler == NULL)
 		conf->default_hwhandler = set_default(DEFAULT_HWHANDLER);
 
+	if (conf->autoname_prefix == NULL)
+		conf->autoname_prefix = set_default(DEFAULT_AUTONAME_PREFIX);
+
 	if (!conf->default_selector  || !conf->udev_dir         ||
 	    !conf->default_getuid    || !conf->default_features ||
 	    !conf->default_hwhandler)

diff -rwup multipath-tools-0.4.5/libmultipath/config.h multipath-tools-0.4.5.new/libmultipath/config.h
@@ -55,6 +55,7 @@ struct config {
 	int pgfailback;
 	int remove;
 	int rr_weight;
+	int autoname;
 
 	char * dev;
 	char * multipath;

@@ -64,6 +65,7 @@ struct config {
 	char * default_getprio;
 	char * default_features;
 	char * default_hwhandler;
+	char * autoname_prefix;
 
 	vector mptable;
 	vector hwtable;

diff -rwup multipath-tools-0.4.5/libmultipath/defaults.h multipath-tools-0.4.5.new/libmultipath/defaults.h
@@ -9,5 +9,7 @@
 #define DEFAULT_PIDFILE		"/var/run/multipathd.pid"
 #define DEFAULT_SOCKET		"/var/run/multipathd.sock"
 #define DEFAULT_CONFIGFILE	"/etc/multipath.conf"
+#define DEFAULT_NAMEFILE	"/etc/multipath.names"
+#define DEFAULT_AUTONAME_PREFIX "multipath%d"
 
 char * set_default (char * str);

diff -rwup multipath-tools-0.4.5/libmultipath/dict.c multipath-tools-0.4.5.new/libmultipath/dict.c
@@ -102,6 +102,17 @@ def_prio_callout_handler(vector strvec)
 }
 
 static int
+def_autoname_prefix_handler(vector strvec)
+{
+        conf->autoname_prefix = set_value(strvec);
+
+        if (!conf->autoname_prefix)
+                return 1;
+
+        return 0;
+}
+
+static int
 def_features_handler(vector strvec)
 {
 	conf->default_features = set_value(strvec);

@@ -129,6 +140,23 @@ def_minio_handler(vector strvec)
 }
 
 static int
+def_autoname_handler(vector strvec)
+{
+        char * buff;
+
+        buff = set_value(strvec);
+
+        if (!buff)
+                return 1; 
+
+        conf->autoname = atoi(buff);
+        FREE(buff);                                             
+                                                                
+        return 0;
+}
+
+
+static int
 def_weight_handler(vector strvec)
 {
 	char * buff;

@@ -590,6 +618,8 @@ init_keywords(void)
 	install_keyword("default_features", &def_features_handler);
 	install_keyword("failback", &default_failback_handler);
 	install_keyword("rr_min_io", &def_minio_handler);
+	install_keyword("autoname", &def_autoname_handler);
+	install_keyword("autoname_prefix", &def_autoname_prefix_handler);
 	install_keyword("rr_weight", &def_weight_handler);
 	
 	install_keyword_root("devnode_blacklist", &blacklist_handler);

It would please old Tru64 fans :/

For one thing, you didn't care to unbork the daemon :)
It tries a mapname (ie alias) to wwid resolution upon map add events. Unphased mpe vector will unduly fail the lookup.

Regards,
cvaroqui

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.

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).

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 hesitate to bring this up on the appropriate list, here:

[email protected]

without any patches :-/

-- Patrick Mansfield

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) ?

FYI, DM currently does its best to circumvent udev. Most distro ship with an "ignore" rule sticked to KERNEL=="dm-*".

Recent upstream multipath-tools also play by that rule : /dev/mapper/ is the only place to find and use multipath maps. /dev/dm-* are also created but only because I couldn't find how to avoid it while still having RUN and PROGRAM directives working.

multipath rules are :

# lookup the devmap name
ACTION=="add", SUBSYSTEM=="block", KERNEL=="dm-*", \
        PROGRAM="/sbin/dmsetup -j %M -m %m --noopencount --noheadings -c
-o name info"

# take care of devmap partitioning
ACTION=="add", SUBSYSTEM=="block", KERNEL=="dm-*", \
        RUN+="/sbin/kpartx -a /dev/mapper/%c"

# insert new paths in multipath topology
ACTION=="add", SUBSYSTEM=="block", KERNEL!="dm-*", \
        RUN+="/sbin/multipath -v0 %r/%k"

Can/will this "outlaw" behaviour persist ?

Are you sure you mean persistent like "stable enumeration accross reboots, and even accross a cluster", or simply persistent like "predictable" ?

Personnaly, I fail to see how to achieve persistance through udev (1st definition, the one PatrickC cares about). Do I miss something ?

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.

I fail to see how this can be done without 1 rule per multipath.

Administrative scalability was the purpose of PatrickC's patch, ie no admin-supplied aliases.

Regards,
cvaroqui

Hi Christophe -

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.

Yes, as long as no one patches/fixes it :)

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).

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.

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.

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.

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

Those are the names I'm trying to free people from.

OK, multipath1 - multipath5000 aren't exactly friendly (but how else are you going to name 5000 disks - there aren't that many Simpsons characters!) but they're are a /lot/ easier to deal with than those I can see there.

patrick

Hi Patrick :)

But we should not have a dm only solution.

For that many disks, I don't see how it helps much, you must still deal with the specific id's at some level. I was thinking more about nice names for a few disks, or splitting disks into groups with a common prefix (and then still keep the long id portion).

Enumerating names in shared/cluster setups probably makes things worse, though you could try to share or copy the file that maps wwid to the enumeration, the same thing for a udev solution.

-- Patrick Mansfield

Good point...

patrick