#2034 PR `merged`: Multipath optimizations¶

Labels: enhancement, fixed / solved / done

rmetrich opened issue at 2019-02-06 09:06:¶

Relax-and-Recover (ReaR) Pull Request Template¶

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

Pull Request Details:¶

Type: Enhancement
Impact: High
Reference to related issue (URL): #2020
How was this pull request tested? Tested by customer
Brief description of the changes in this pull request:

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

With these optimizations, the ReaR rescue takes a few minutes only.

rmetrich commented at 2019-02-06 10:38:¶

@schabrolles Could you please test also on one of your systems with multipath

schabrolles commented at 2019-02-06 10:52:¶

@rmetrich, I'm in a workshop all day but will try it ASAP (tomorrow)

rmetrich commented at 2019-02-07 15:50:¶

Internal report from Red Hat QA:

tests using multipath instead of lvm (simulating the original problem more closely):

     yum install rear device-mapper-multipath
     modprobe scsi_debug max_luns=2 num_tgts=200 add_host=3 vpd_use_hostno=0
     mpathconf --enable --with_multipathd y

wait for multipath to settle
     multipath -l | wc -l
should show 3200, if less, wait more

     time rear -v -d -D mkrescue

takes 42 min without the fix, 2min 33s with the fix.

[Export of Github issue for rear/rear.]

#2034 PR merged: Multipath optimizations¶