#2690 Issue closed: 300_map_disks.sh insufficient to automatically find existing unique disk size mapping

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

jsmeix opened issue at 2021-10-04 13:19:

  • ReaR version ("/usr/sbin/rear -V"):
    current GitHub master code

  • Description of the issue (ideally so that others can reproduce it):

Assume on the original sytem the disks with sizes are

sda 1000
sdb 2000
sdc 3000
sdd 4000

Assume on the replacement hardware the disks with sizes are

sda 4000
sdb 1000
sdc 2000
sdd 3000

In this case a unique disk mapping based on disk size exits
(source target):

sda sdb
sdb sdc
sdc sdd
sdd sda

But current layout/prepare/default/300_map_disks.sh
is overcautious in this particular case here
because it skips when a possibly found target system disk
is already listed as source or target in the mapping file.

First it reads disk sda 1000 from disklayout conf
and finds the unique size matching sdb on the replacement hardware
so it autogenerates the following line in the mapping file:

sda sdb

Next it reads disk sdb 2000 from disklayout conf and
tries to find if there is a current disk with same name and same size as the original
but as sdb is already listed as target disk in the generated mapping file
it skips that mapping.

Then it reads disk sdc 3000 from disklayout conf
and finds the unique size matching sdd on the replacement hardware
so it autogenerates sdc sdd and add it to the mapping file:

sda sdb
sdc sdd

Finally it reads disk sdd 4000 from disklayout conf and
tries to find if there is a current disk with same name and same size as the original
but as sdd is already listed as target disk in the generated mapping file
it skips that mapping.

The main reason for what looks overcautious in this particular case
is when the user has provided a mapping file.
Then the automatism must not get in conflict with disks
from the user provided mapping.
I.e. the user provided mapping must be sacrosanct.
Currently user provided mapping is not distinguished from the
generated automated mapping. All is in one single mapping file.

Another reason is that the automatism must not get in conflict with
what is has already specified in its autogenerated mapping file
(e.g. no disk must be used twice as source or target).

So the automated mapping code in 300_map_disks.sh
needs some major rework.

  • Workaround, if any:

As user manually add the missing mappings via the dialogs that are shown by ReaR.

jsmeix commented at 2021-10-05 15:21:

https://github.com/rear/rear/pull/2693 should fix this issue here
but it needs some more testing with some different cases
to avoid possible regressions in other cases.

pcahyna commented at 2021-10-13 17:25:

@jsmeix without trying the code, I have the impression that your reproducer is needlessly complicated. Wouldn't original disks

sda 1000
sdb 2000

and replacement disks

sda 2000
sdb 1000

be enough to reproduce the problem? First, sda would be mapped to sdb and then sdb would be skipped.

jsmeix commented at 2021-10-14 07:56:

@pcahyna my initial description of the issue is based
on a SUSE customer issue who had 4 disks.
It is not the smallest possible reproducer.

pcahyna commented at 2021-10-14 08:51:

@jsmeix I see, and is my reasoning above correct, or am I missing something?

jsmeix commented at 2021-10-14 09:06:

@pcahyna
I would have to test with two disks to know for sure
but in https://github.com/rear/rear/pull/2693
I didn't test with two disks

jsmeix commented at 2021-10-15 10:34:

I tested two disks, see
https://github.com/rear/rear/pull/2693#issuecomment-944190272

jsmeix commented at 2021-10-15 10:34:

With https://github.com/rear/rear/pull/2693 merged
this issue should be fixed.

[Export of Github issue for rear/rear.]