Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

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:
In the midst of removing and re-establishing multipath FC disks (via FCoE), the multipathd daemon marked the disk to read-only (DISK_RO=1) for an extended period of time which led to 'Operation not permitted' failures in the disk-write application.  Note that for this specific case, the link toggle was caused by the HP interconnect reboot test.

Version-Release number of selected component (if applicable):
This was observed with the device-mapper-multipath under RHEL6.4 GA

How reproducible:
Reproducible after 3-4 hours of testing

Steps to Reproduce:
1. Establish FCoE disks with multipath
2. Continuously do write I/Os to the disks
3. toggle remote FC links

Actual results:
After a few hours of testing, the test application will fail with the 'Operation not permitted' message for the failed write command due to the disk being marked RO.

Expected results:
In this multipath environment, there's always a path to the FC disk.  So for every link toggle event, the multipathd daemon should be able to react and change the path accordingly.

Additional info:

Created attachment 806809 [details]
multipathd log which contains the 'DISK_RO=1' message

Created attachment 806810 [details]
corresponding message log

Created attachment 806811 [details]
Application error log with 'Operation not permitted'

This looks like it might be a dup of Bug #958091.  The issue is that whenever multipath fails reloading a table, it retried read-only. In case a device was read-only.  The fix for Bug #958091, was to only try this reload if the table-load failed with an error of EROFS.  Can you please try the latest packages (device-mapper-multipath-0.4.9-71.el6) available at:

http://people.redhat.com/bmarzins/device-mapper-multipath/rpms/RHEL6/x86_64/

and

http://people.redhat.com/bmarzins/device-mapper-multipath/rpms/RHEL6/i686/

and let me know if this resolves the issue.

Thanks, Ben.  We are still working to verify your patch.  I'll be sure to keep you posted on our findings.

This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

I'm pretty sure this is a dup, as mentioned in Comment 5.  It's been two years, with no response from the reporter on verifying this, so I'm closing the bug.

*** This bug has been marked as a duplicate of bug 958091 ***