Description of problem:
When a system has many multipath devices (547 disks, 272 x 2 paths), creating the ReaR rescue takes several hours. This is due to:
* the `get_device_name()` function to scan all multipath devices multiple times without caching the information (legacy code, when kernel has no `/sys/block/<dev>/dm/name` node)
* the `get_device_name()` function to scan the multipath devices even if there is no need for that
* the collect of unused `/sys/class/fc_transport` information
Version-Release number of selected component (if applicable):
rear-2.00 and rear-2.4.2
Always with tons of multipath devices
ReaR rescue takes several hours
ReaR rescue takes a couple of minutes
Is there a way to reproduce without multipath devices? Would the problem show up with hundreds of non-multipath disks? I suppose that the fact that multipath devices use device-mapper is the key. Would another device-mapper type trigger the problem (e.g. if one had hundreds of logical volumes instead)?
AFAICT, the issue will show up only on kernels which do not have /sys/block/<dev>/dm/name. How old must the kernel be for that?
> AFAICT, the issue will show up only on kernels which do not have /sys/block/<dev>/dm/name. How old must the kernel be for that?
No, the current code is broken and as soon as the raw device (e.g. "/dev/sda") has to be resolved through get_device_name(), the code goes through scanning all multipath devices, because /dev/sda is no device mapper.
this will need a RHEL 8 clone, right? Otherwise we will have a regression in 8 compared to 7.y.z.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.