Bug 1672938

Summary:	ReaR unable to create the Rescue ISO when having a lot of multipath devices
Product:	Red Hat Enterprise Linux 7	Reporter:	Renaud Métrich <rmetrich>
Component:	rear	Assignee:	Pavel Cahyna <pcahyna>
Status:	CLOSED ERRATA	QA Contact:	David Jež <djez>
Severity:	medium	Docs Contact:
Priority:	urgent
Version:	7.6	CC:	djez, fkrska, ovasik, pcahyna, rmetrich
Target Milestone:	rc	Keywords:	Patch, Reproducer, ZStream
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	rear-2.4-4.el7	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:
Clones:	1673978 1680484 1680485 1680486 (view as bug list)		Environment:
Last Closed:	2019-08-06 13:12:09 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1673978, 1680484, 1680485, 1680486, 1691303, 1726142

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