RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Description of problem:

Sanlock has complex timeouts based on I/O timeout (default 10 seconds) used
to renew delta leases and check host liveliness. These operations cannot
use arbitrary timeout or user configurable timeout.

The timeouts are documented here:
https://pagure.io/sanlock/blob/master/f/src/timeouts.h

Sanlock reuse the same base timeout (10 secodns) for other storage operations 
like formatting lockspace area, formatting resource area, creating rindex.
These operations can use arbitrary timeout or user configurable timeout.

A single timeout when renewing a lease is not critical, since the operation
is retried in the next check interval.

Single timeout when creating a lockspace or reosource fail the operation in
the management system using sanlock.

In oVirt system tests, running on virtualized environment, with unpredictable
load, we experience too much failures in sanlock operations that could be 
avoided if we had larger timeout.

Use separate timeout for normal storage operations, with larger default value
so these operations are less likely to fail on overloaded environments.

Make the new timeout configurable so users can adapt the timeout as needed.

Related patch in review:
https://pagure.io/sanlock/c/3268693b861d1886af19f3fc75b67b28c3cbd572?branch=test-sched2

Fixed verified in the latest rpms. I adjusted the write_init_io_timeout setting to a variety of values and saw no issues during VG creation while running standard lvmlockd+sanlock regression testing.


sanlock-3.8.2-1.el8    BUILT: Mon Aug 10 12:12:49 CDT 2020
sanlock-lib-3.8.2-1.el8    BUILT: Mon Aug 10 12:12:49 CDT 2020

kernel-4.18.0-234.el8    BUILT: Thu Aug 20 12:01:26 CDT 2020
lvm2-2.03.09-5.el8    BUILT: Wed Aug 12 15:51:50 CDT 2020
lvm2-libs-2.03.09-5.el8    BUILT: Wed Aug 12 15:51:50 CDT 2020
lvm2-lockd-2.03.09-5.el8    BUILT: Wed Aug 12 15:51:50 CDT 2020

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 (sanlock bug fix and enhancement update), 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-2020:4595