Bug 185388 - Ordering of NFS exports
Ordering of NFS exports
Status: CLOSED ERRATA
Product: Red Hat Cluster Suite
Classification: Red Hat
Component: rgmanager (Show other bugs)
4
All Linux
medium Severity medium
: ---
: ---
Assigned To: Lon Hohberger
Cluster QE
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-03-14 02:47 EST by birger
Modified: 2009-04-16 16:19 EDT (History)
1 user (show)

See Also:
Fixed In Version: RHBA-2006-0557
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-08-10 17:21:50 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Adds ability to disable recovery (causing service restart) (1.68 KB, patch)
2006-05-16 13:05 EDT, Lon Hohberger
no flags Details | Diff

  None (edit)
Description birger 2006-03-14 02:47:52 EST
Description of problem:
There should be some way to ensure ordering of nfs exports.
When there are multiple export lines for a given file system, ordering of these
is often important (to grant root access, insecure option for NAT gateways,
read-only vs read-write, etc)

Version-Release number of selected component (if applicable):


How reproducible:
Sometimes NFS filesystems get reexported by the cluster, either because some
export got deleted, because of configuration changes, etc... This reexporting
(or even the initial export when the cluster starts) doesn't preserve the
ordering of NFS exports from the config file.


Steps to Reproduce:
1. Delete some export
2. Wait
3. The export reappears, but not in the order it is specified in the config file
  
Actual results:


Expected results:
When an export for a given file system must be refreshed, all exports for that
filesystem should be refreshed in the correct order.


Additional info:
It would be fully acceptable (at least to me) to have an extra attribute in the
XML file to specify the ordering if it is difficult to preserve ordering of the
parsed data. Order is only important within one export point as far as I can see.
Comment 1 Lon Hohberger 2006-05-12 15:38:07 EDT
Removing the recover tag should solve this for you for now - that should cause a
full restart.
Comment 2 Lon Hohberger 2006-05-16 13:05:31 EDT
Created attachment 129235 [details]
Adds ability to disable recovery (causing service restart)

There's no easy way to make rgmanager do "restart this entire branch of a
service tree as a recovery operation".	For now, we'll just allow loss of a
specific exports to trigger a service bounce.

   Add allow_recovery="0" to any nfs client where that client is fatal.

Less than ideal, but it works.	In a future release, we may add inheritance
support (e.g. the way fsid works) so that you don't need to set this as a
per-client option.
Comment 3 birger 2006-05-16 17:41:14 EDT
I have patched the file and edited my config. Just a bit too chicken to actually
test it right now... We will have to bring down the whole server room within the
next weeks so I'll test then.

By the way... Looking at the patch, it seems like I should add allow_recover=0,
not allow_recovery.
Comment 4 Lon Hohberger 2006-05-17 09:41:49 EDT
correct -- allow_recover="0" :)
Comment 7 Red Hat Bugzilla 2006-08-10 17:21:52 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2006-0557.html

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