#1765 PR merged: Fix partition replacement

Labels: enhancement, bug, documentation, fixed / solved / done

schabrolles opened issue at 2018-04-01 07:54:

Relax-and-Recover (ReaR) Pull Request Template

Please fill in the following items before submitting a new pull request:

Pull Request Details:

  • Type: Bug Fix

  • Impact: Normal

  • Reference to related issue (URL):

  • How was this pull request tested?
    Tested in PowerVM environment, with RHEL7.4, with a disk Migration.

  • Brief description of the changes in this pull request:
    RedHat use to add no prefix between multipath device name a partition number (ex: /dev/mapper/mpatha1"). In that case, multipath optionuser_friendly_nameis activated (which is RedHat default). Whenuser_friendly_nameis disabled, RedHat adds a **"p"** prefix between multipath device name (WWID in that case) and partition number. (ex:/dev/mapper/3600507680c82004cf8000000000000d8p1`).

I propose the following:

  • During the 1st replacement change, replace ALL known partition naming variant by REARX.
    (/dev/mapper/mpatha1, /dev/mapper/mpathap1, /dev/mapper/maptha-part1, /dev/mapper/maptha_part1) will by _REAR1_1

  • During the 2nd replacement, check if the current system is a Redhat with "user_friendly_name" deactivated, recreate the partition device by adding "p" between device name and partition number.

=> This will solve the issue when a user is using a RedHat with "user_friendly_name" deactivated.
And avoid a problem during a migration when a user wants to switch "user_friendly_name" during the restoration phase.

jsmeix commented at 2018-04-03 10:04:

@schabrolles
recently I noticed a mail on an internal SUSE mailing list
that reads (excerpts):

> is there a way to enable multipath
> and have "friendly names enabled"...
> For example /dev/mapper/mpath0
...
If you are happy with the default user_friendly_names
("mpatha", "mpathb", etc), you can add...
/etc/multipath.conf

defaults {
    user_friendly_names yes
}

so that also on SUSE systems there can be
multipath device nodes with user_friendly_names.

Accordingly I think in the (SUSE) case
the whole current code is also only valid
if is_false "$user_friendly_names"

schabrolles commented at 2018-04-03 10:18:

@jsmeix,

You are right, I just need to know how Suse will name the partition device when user_friendly_names is set to true.
/dev/mapper/mapatha1 or /dev/mapper/mpathap1 ... or something else ... :)

jsmeix commented at 2018-04-03 10:50:

I asked on that internal SUSE mailing list.

If you like to merge your current changes soon,
I think you can just do it and do the SUSE related enhancements
later via a separated pull request.

As far as I noticed it is rather complicated to install a SUSE system
with user_friendly_names yes so that - at least for now - we could
probably safely assume that this case does not happen in practice
on SUSE systems.

Perhaps to be safe against weird errors later at unexpected places in the code a

    (SUSE)
        if is_true "$user_friendly_names" ; then
            Error "Multipath with user_friendly_names is not supported on SUSE systems"
        fi
        ...

might be added right now?

jsmeix commented at 2018-04-03 12:18:

My question and the reply
on that internal SUSE mailing list
(full excerpt as far as it matters here):

> Could you tell me (or point to a public accessible URL)
> how each SLE version names the multipath device nodes
> when 'user_friendly_names yes' is set and ideally also
> when 'user_friendly_names no' is set.
> 
> For example /dev/mapper/mapatha1, /dev/mapper/mapatha2,...
> or /dev/mapper/mpathap1, /dev/mapper/mpathap2,...
> or something else?

AFAICS, the basic user_friendly_names scheme
has been stable since ~2008. The names
are "mpath$X", where $X is built up like
a SCSI device ID:
mpatha,...,mpathz,mpathaa,...,mpathaz,mpathba,...,mpathzz,mpathaaa,...

That said, the device name prefix ("mpath") is configurable
in multipath.conf ("alias_prefix", certainly a rarely used option,
but it exists). Names are looked up in /etc/multipath/bindings
and re-used between reboots.

Without user_friendly names, the device name is determined
by the WWID, which is udev property ID_SERIAL
for SCSI devices and ID_WWN for most other devices.

You can use `multipathd show maps format "%w %n"`
to find out the relationship between WWID (%w)
and name (%n) of multipath devices.

The rest of your question seems to relate
to *partition* naming.

> In particular I would like to know where the naming scheme
> is different for different SLE versions.
> 
> For example in SLE11 non-user_friendly_names were like
> /dev/mapper/3600507680c82004cf8000000000000d8_part1
> while since SLE 12 it is like
> /dev/mapper/3600507680c82004cf8000000000000d8-part1
> (i.e. '_part' versus '-part')

Yes, _part$n has been replaced by -part$n in SLE12.
But there are compatibility links. This is determined
by the udev rules file "66-kpartx.rules".

> but we don't know what it was for SLE10

Sorry I don't know either. Does it really matter still?

> and we don't know what it might be for SLE15.

... will be like SLE12 (-part$n). The _part$n
compatibility links aren't present any more.

> FYI - for even more fun with that:
> Additionally Red Hat (ReaR works for SLE and RHEL)
> names its multipath device nodes differently ;-)

It seems they aren't shipping 66-kpartx.rules.
They are using the kernel default naming scheme,
which is "p$N" for parent devices ending with a digit,
and just "$n" for parent devices ending in a non-digit.
That's horrible, in particular if you don't
use user_friendly_names.

jsmeix commented at 2018-04-03 13:19:

One more of my questions and the reply
on that internal SUSE mailing list
(full excerpt as far as it matters here):

> > AFAICS, the basic user_friendly_names scheme has been
> > stable since ~2008. The names are "mpath$X", where $X
> > is built up like a SCSI device ID:
> >
> mpatha,...,mpathz,mpathaa,...,mpathaz,mpathba,...,mpathzz,mpathaaa,..
> .
> ...
> > The rest of your question seems to relate to *partition* naming.
> ...
> > Yes, _part$n has been replaced by -part$n in SLE12.
> > This is determined by the udev rules file
> > "66-kpartx.rules".
> 
> sorry, my question was not precise.
> 
> Actually my question was primarily about partition naming.
> 
> How do partition names look like with user_friendly_names?
> 
> mpatha1, mpatha2, ... mpathb1, mpathb2, ...
> (this is how it looks on Red Hat systems)
> or
> mpatha-part1, mpatha-part2, ... mpathb-part1, mpathb-part2, ...
> 
> I ask because I do not understand how 66-kpartx.rules
> works in case of user_friendly_names.

The rules don't distinguish whether or not
user_friendly_names is in use.
The rule which does the job is:

RUN+="/sbin/kpartx -u -p -part /dev/$name"

kpartx constructs the name of the partition device
from the name of the parent device
using the value of the "-p" option:

/dev/mapper/foo => /dev/mapper/foo-part1

Btw,
for the device-mapper *UUID*,
the part$n is not appended but prepended:

mpath-3600a098000aad73f00000a3f5a275dc8
=> part1-mpath-3600a098000aad73f00000a3f5a275dc8

Unlike the name, this is hard-coded and not configurable.

schabrolles commented at 2018-04-16 06:58:

@jsmeix thanks to you and your team in suse for that useful information.
That also confirms my experiments:
Suse:

  • <12 : always <device>_part<part_num> (same with/without user_friendly_names)
  • >=12 : always <device>-part<part_num> (same with/without user_friendly_names)
    Question still open for sles10 ...

RedHat:

  • <7 : always <device>p<part_num> (same with/without user_friendly_names)
  • >=7 : if user_friendly_names (default) <device><part_num> else <device>p<part_num>

Debian:

  • if user_firendly_names (default) <device>-part<part_num>
  • if NOT user_firendly_names <device>p<part_num>

So checking user_firendly_names make sense only for Fedora & Debian based system.

jsmeix commented at 2018-04-16 08:26:

@schabrolles
don't worry about SLES10 because
since ReaR 1.17 we had dropped officially support for SLES10,
see the doc/rear-release-notes.txt diff in
https://github.com/rear/rear/commit/86009877e7ae15d768d9eb3b6d0e660118dfdf42

What I do regarding SLES10 support in ReaR is that
I do not knowingly break existing SLES10 support
but I do not check if each change keeps SLES10 support
i.e. my changes may unknowingly break existing SLES10 support.

jsmeix commented at 2018-04-16 08:34:

@schabrolles
could you edit your above https://github.com/rear/rear/pull/1765#issuecomment-381498504
and make it clear what about the cases when Suse = 12 and Fedora = 7
by using less-than-or-equal or greater-than-or-equal signs because
your https://github.com/rear/rear/pull/1765#issuecomment-381498504
is a good general summary - or even better:
Could you add that summary as comment directly in the code
so that others who may have to adapt and enhance that code
at any later time get a better understanding about the various
multipath device naming schemes.

schabrolles commented at 2018-04-16 08:39:

@jsmeix
ok, I'll test it during the day and merge it tomorrow if everything is ok.

jsmeix commented at 2018-04-16 08:55:

@gdha
could you do your review here?
( or a comment that you blindly trust @schabrolles )

[Export of Github issue for rear/rear.]