Description of problem: See https://github.com/rear/rear/pull/2034 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 How reproducible: Always with tons of multipath devices Actual results: ReaR rescue takes several hours Expected results: 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.
indeed
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. https://access.redhat.com/errata/RHBA-2019:2273