[PATCH] [RFC] persistent readable names

[PATCH] [RFC] persistent readable names

[Patrick Caulfield]

[-- Attachment #1: Type: text/plain, Size: 1058 bytes --]

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

[-- Attachment #2: mpauto.patch --]
[-- Type: text/x-patch, Size: 6778 bytes --]

diff -rwup multipath-tools-0.4.5/libmultipath/config.c multipath-tools-0.4.5.new/libmultipath/config.c
--- multipath-tools-0.4.5/libmultipath/config.c	2005-09-02 14:14:18.000000000 +0100
+++ multipath-tools-0.4.5.new/libmultipath/config.c	2005-10-05 13:39:33.000000000 +0100
@@ -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
--- multipath-tools-0.4.5/libmultipath/config.h	2005-09-02 14:14:18.000000000 +0100
+++ multipath-tools-0.4.5.new/libmultipath/config.h	2005-10-05 13:39:33.000000000 +0100
@@ -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
--- multipath-tools-0.4.5/libmultipath/defaults.h	2005-09-02 14:14:18.000000000 +0100
+++ multipath-tools-0.4.5.new/libmultipath/defaults.h	2005-10-05 13:39:33.000000000 +0100
@@ -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
--- multipath-tools-0.4.5/libmultipath/dict.c	2005-09-02 14:14:18.000000000 +0100
+++ multipath-tools-0.4.5.new/libmultipath/dict.c	2005-10-05 14:27:52.000000000 +0100
@@ -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);
diff -rwup multipath-tools-0.4.5/multipath/main.c multipath-tools-0.4.5.new/multipath/main.c
--- multipath-tools-0.4.5/multipath/main.c	2005-10-05 14:22:06.000000000 +0100
+++ multipath-tools-0.4.5.new/multipath/main.c	2005-10-05 13:56:40.000000000 +0100
@@ -642,6 +642,42 @@ domap (struct multipath * mpp)
 	return r;
 }
 
+
+static void
+autoname_mpp(struct multipath *mpp)
+{
+	int i;
+	struct mpentry *mpe;
+	FILE *namefile;
+	static int highest = 0;
+
+/* Look through the list of multipaths and look for the next highest autoname number.
+   We then assign that to the passed-in mpp and add it to the multipath.names file */
+
+	/* Only need to scan it once */
+	if (!highest) {
+		vector_foreach_slot (conf->mptable, mpe, i) {
+
+			int thisnum;
+
+			if (mpe->alias && sscanf(mpe->alias, conf->autoname_prefix, &thisnum) == 1)
+				if (thisnum > highest)
+					highest = thisnum;
+		}
+	}
+	highest++;
+	mpp->alias = MALLOC(strlen(conf->autoname_prefix)+10);
+	sprintf(mpp->alias, conf->autoname_prefix, highest);
+
+	/* Add an entry to the names file */
+	namefile = fopen(DEFAULT_NAMEFILE, "a");
+	if (!namefile) {
+		return;
+	}
+	fprintf(namefile, "%s\t%s\n", mpp->wwid, mpp->alias);
+	fclose(namefile);
+}
+
 static int
 coalesce_paths (vector curmp, vector pathvec)
 {
@@ -681,6 +717,8 @@ coalesce_paths (vector curmp, vector pat
 		strcpy(mpp->wwid, pp1->wwid);
 		mpp->size = pp1->size;
 		mpp->paths = vector_alloc();
+		if ((!mpp->alias || mpp->alias == mpp->wwid) && conf->autoname)
+			autoname_mpp(mpp);
 
 		if (pp1->priority < 0)
 			mpp->action = ACT_NOTHING;
@@ -839,6 +877,61 @@ get_dm_mpvec (vector curmp, vector pathv
 	return 0;
 }
 
+static void
+load_autonames(char *fname)
+{
+	char buf[1024];
+	char *alias;
+	int i;
+	struct mpentry *mpe;
+
+	stream = fopen(fname, "r");
+	if (!stream)
+		return; /* File is optional */
+
+	while (read_line(buf, sizeof(buf))) {
+		alias = strchr(buf, '\t');
+		if (!alias)
+			continue;
+		*alias = '\0';
+		alias++;
+
+		/* Look for the WWID and store its autogenerated alias */
+		vector_foreach_slot (conf->mptable, mpe, i) {
+			if (!strcmp(mpe->wwid, buf)) {
+				if (!mpe->alias || mpe->alias == mpe->wwid) {
+					mpe->alias = MALLOC(strlen(alias)+1);
+					if (mpe->alias)
+						strcpy(mpe->alias, alias);
+					break; /* back to read_line loop */
+				}
+			}
+		}
+		/* no mpentry found - need to create one */
+		mpe = alloc_mpe();
+		if (!vector_alloc_slot(conf->mptable)) {
+			FREE(mpe);
+			return;
+		}
+		mpe->wwid = MALLOC(strlen(buf)+1);
+		if (!mpe->wwid) {
+			FREE(mpe);
+			return;
+		}
+		mpe->alias = MALLOC(strlen(alias)+1);
+		if (!mpe->alias) {
+			FREE(mpe->wwid);
+			FREE(mpe);
+			return;
+		}
+		strcpy(mpe->wwid, buf);
+		strcpy(mpe->alias, alias);
+		vector_set_slot(conf->mptable, mpe);
+        }
+
+	fclose(stream);
+}
+
 int
 main (int argc, char *argv[])
 {
@@ -1006,7 +1099,10 @@ main (int argc, char *argv[])
 	if (conf->list)
 		goto out;
 
+	/* This has auto-named paths in it */
+	load_autonames(DEFAULT_NAMEFILE); 
+
 	/*
 	 * core logic entry point
 	 */
 

[-- Attachment #3: Type: text/plain, Size: 0 bytes --]

Re: [PATCH] [RFC] persistent readable names

[Christophe Varoqui]

On Wed, Oct 05, 2005 at 03:14:52PM +0100, Patrick Caulfield wrote:
> 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.
>
It would please old Tru64 fans :/

> There are a small number of possibly contentious things:
>
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

Re: [PATCH] [RFC] persistent readable names

[Patrick Mansfield]

On Wed, Oct 05, 2005 at 05:09:23PM +0200, Christophe Varoqui wrote:
> On Wed, Oct 05, 2005 at 03:14:52PM +0100, Patrick Caulfield wrote:
> > 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.

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:

	linux-hotplug-devel@lists.sourceforge.net 

without any patches :-/

-- Patrick Mansfield

Re: [PATCH] [RFC] persistent readable names

[Christophe Varoqui]

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


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 ?

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

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.

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

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

Regards,
cvaroqui

Re: [PATCH] [RFC] persistent readable names

[Patrick Mansfield]

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

Re: [PATCH] [RFC] persistent readable names

[Patrick Caulfield]

Patrick Mansfield wrote:

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


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

Re: [PATCH] [RFC] persistent readable names

[Patrick Mansfield]

Hi Patrick :)

On Thu, Oct 06, 2005 at 08:07:36AM +0100, Patrick Caulfield wrote:
> Patrick Mansfield wrote:
> 
> > 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. 
> > 

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

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

Re: [PATCH] [RFC] persistent readable names

[Patrick Caulfield]

Christophe Varoqui wrote:
> On Wed, Oct 05, 2005 at 03:14:52PM +0100, Patrick Caulfield wrote:
> 
>>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.
>>
> 
> It would please old Tru64 fans :/
> 
> 
>>There are a small number of possibly contentious things:
>>
> 
> 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.

Good point...

-- 

patrick