New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
300_map_disks.sh insufficient to automatically find existing unique disk size mapping #2690
Comments
In layout/prepare/default/300_map_disks.sh overhauled the automapping of original 'disk' devices and 'multipath' devices to current block devices in the currently running recovery system see #2690
#2693 should fix this issue here |
@jsmeix without trying the code, I have the impression that your reproducer is needlessly complicated. Wouldn't original disks
and replacement disks
be enough to reproduce the problem? First, |
@pcahyna my initial description of the issue is based |
@jsmeix I see, and is my reasoning above correct, or am I missing something? |
In layout/prepare/default/300_map_disks.sh overhauled the automapping of original 'disk' devices and 'multipath' devices to current block devices in the currently running recovery system so that now it automatically finds an existing unique disk size mapping also when there is a unique mapping between more than two disks, see #2690
I tested two disks, see |
With #2693 merged |
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
Assume on the replacement hardware the disks with sizes are
In this case a unique disk mapping based on disk size exits
(source target):
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 confand finds the unique size matching
sdb
on the replacement hardwareso it autogenerates the following line in the mapping file:
Next it reads
disk sdb 2000
from disklayout conf andtries 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 fileit skips that mapping.
Then it reads
disk sdc 3000
from disklayout confand finds the unique size matching
sdd
on the replacement hardwareso it autogenerates
sdc sdd
and add it to the mapping file:Finally it reads
disk sdd 4000
from disklayout conf andtries 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 fileit 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.
As user manually add the missing mappings via the dialogs that are shown by ReaR.
The text was updated successfully, but these errors were encountered: