Red Hat Bugzilla – Bug 185388
Ordering of NFS exports
Last modified: 2009-04-16 16:19:54 EDT
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):
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
3. The export reappears, but not in the order it is specified in the config file
When an export for a given file system must be refreshed, all exports for that
filesystem should be refreshed in the correct order.
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.
Removing the recover tag should solve this for you for now - that should cause a
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
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,
correct -- allow_recover="0" :)
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.