nfsserver fixes and cleanup #420
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…y or else lock recovery fails sm-notify drops root privileges and executes as the rpc user. If we do not maintain the statd ownership correctly sm-notify can not access the lock state data.
If a nfsserver restarts on a node without rebooting, the lock notifications are not sent out properly because of a stale sm-notify.pid file. In normal non-ha operation, this is to prevent sm-notify from notifying clients multiple times, but in an ha environment we need this to occur.
nfs clients use lock services outside of ha nfs server
Previously the nfsserver agent took in what binary to use in order to send the NSM lock notifications. We don't need to know what binary to use. It only makes sense to use sm-notify if rpc.statd is already running as sm-notify re-notifies the clients of a change. If rpc.statd is down, it has to be started for NSM locking to occur. By default rpc.statd is going to invoke sm-notify on initialization. So, if rpc.statd is down. We use rpc.statd to notify on start. If rpc.statd is up, we use sm-notify to re-notify clients. I've also made the nfs_ip argument optional. There are use-cases where we do not want to bind rpc.statd to the floating ip. If no nfs_ip is specified, rpc.statd binds to the wildcard address. One more change to rpc.statd has been made. I removed the ability to accidently execute rpc.statd in the foreground. rpc.statd never returns. It is a daemon... This would cause start to timeout if anyone ever set this option and rpc.statd was used to notify the clients.
… has trailing slash
This increases the recommended stop time from 10s to 120s. This will help mitigate users running into the problem where they need to wait out the nfsv4 lease time during stop, but the stop timeout is too short which causes the resource to fail. It is very common for the nfsv4 lease timeout to be 90 seconds. Increasing the stop timeout to 120s gives us plenty of room to work with here for the majority of use-cases.
|
I feel confident in the direction I'm taking here with these patches. I'm going to merge what I have because I already have another set of patches that need to go on top of this work. If my changes happen to cause a regression for your use-case, file a bug and I'll address it. |
davidvossel
added a commit
that referenced
this pull request
May 13, 2014
nfsserver fixes and cleanup
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I've been working with the nfsserver and exportfs agents for the past couple of weeks. I'm sure I'll have more fixes/changes, but this current set of changes I have now seems like a good place to start.
Most of what I've done does not affect anyone already using these agents. The only major change here is the removal of the requirement to specify a set of floating ip addresses to the nfsserver agent's nfs_ip option. This 'nfs_ip' option was used in conjunction with the sm_notify/rpc.statd binaries in an attempt to send SM_NOTIFY requests originating from the floating IPs to the nfs clients. There are use-cases where this functionality is neither necessary nor desired. All I did was make nfs_ip argument optional rather than required.
The other changes are minor and mostly only affect the systemd use-case I've been working with for rhel.