[dm-devel] [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