Bug 1672938 - ReaR unable to create the Rescue ISO when having a lot of multipath devices
Summary: ReaR unable to create the Rescue ISO when having a lot of multipath devices
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: rear
Version: 7.6
Hardware: All
OS: Linux
urgent
medium
Target Milestone: rc
: ---
Assignee: Pavel Cahyna
QA Contact: David Jež
URL:
Whiteboard:
Depends On:
Blocks: 1673978 1680484 1680485 1680486 1691303 1726142
TreeView+ depends on / blocked
 
Reported: 2019-02-06 09:38 UTC by Renaud Métrich
Modified: 2019-09-15 13:03 UTC (History)
5 users (show)

Fixed In Version: rear-2.4-4.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1673978 1680484 1680485 1680486 (view as bug list)
Environment:
Last Closed: 2019-08-06 13:12:09 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2019:2273 None None None 2019-08-06 13:12:19 UTC
Github rear rear pull 2034 'None' 'closed' 'Multipath optimizations' 2019-11-26 04:03:45 UTC
Red Hat Knowledge Base (Solution) 4415771 None None None 2019-09-15 13:03:50 UTC

Description Renaud Métrich 2019-02-06 09:38:26 UTC
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

Comment 4 Pavel Cahyna 2019-02-06 14:29:24 UTC
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)?

Comment 5 Pavel Cahyna 2019-02-06 15:07:23 UTC
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?

Comment 6 Renaud Métrich 2019-02-06 15:13:27 UTC
> 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.

Comment 14 Pavel Cahyna 2019-02-07 15:46:09 UTC
this will need a RHEL 8 clone, right? Otherwise we will have a regression in 8 compared to 7.y.z.

Comment 15 Renaud Métrich 2019-02-07 15:47:24 UTC
indeed

Comment 26 errata-xmlrpc 2019-08-06 13:12:09 UTC
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


Note You need to log in before you can comment on or make changes to this bug.