+++ This bug was initially created as a clone of Bug #1338967 +++ Description of problem: The surviving ganesha.nfsds are put into NFS-GRACE after a fail-over (triggered when one of the ganesha.nfsds dies). When the ganesha.nfsd is restarted and the floating IP (VIP) fails back, the original surviving ganesha.nfsds should be put into NFS-GRACE again for post fail-back lock recovery, etc. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
REVIEW: http://review.gluster.org/14507 (common-ha: post fail-back, ganesha.nfsds are not put into NFS-GRACE) posted (#1) for review on release-3.8 by Kaleb KEITHLEY (kkeithle)
COMMIT: http://review.gluster.org/14507 committed in release-3.8 by Niels de Vos (ndevos) ------ commit 0674009b527fc853771b82b5dae14aa858d691b2 Author: Kaleb S KEITHLEY <kkeithle> Date: Mon May 23 15:27:23 2016 -0400 common-ha: post fail-back, ganesha.nfsds are not put into NFS-GRACE A little known, rarely used feature of pacemaker called "notification" is used to follow the status of the ganesha.nfsds in the cluster. This is done with location constraints and other Black Magick. When a nfsd dies, the ganesha-active attribute is cleared, the associated floating IP (VIP) fails over to another node, and the ganesha_grace notify method is invoked with post-stop on all the nodes where the ganesha.nfsd is still running. The notify methods send dbus msgs to put their nfsds into NFS-GRACE, and the nfsds perform their grace processing, e.g. taking over locks from the failed nfsd. N.B. Fail-back was originally not planned to be a feature for glusterfs-3.7, but we sorta got it for free. For fail-back, the opposite occurs. The ganesha-active attribute is recreated, the floating IP fails back, and the notify method is invoked with pre-start on all the nodes where the surviving ganesha.nfsds continue to run. The notify methods send dbus msgs again to put their nsfds into NFS-GRACE again, and the nfsds clean up their locks. Backport mainline > http://review.gluster.org/14506 > BUG 1338967 Change-Id: I3fc64afa20ae3a928143d69aa533a8df68dd680e BUG: 1338968 Signed-off-by: Kaleb S KEITHLEY <kkeithle> Reviewed-on: http://review.gluster.org/14507 Smoke: Gluster Build System <jenkins.com> NetBSD-regression: NetBSD Build System <jenkins.org> CentOS-regression: Gluster Build System <jenkins.com> Reviewed-by: soumya k <skoduri> Reviewed-by: Niels de Vos <ndevos>
This bug is getting closed because a release has been made available that should address the reported issue. In case the problem is still not fixed with glusterfs-3.8.0, please open a new bug report. glusterfs-3.8.0 has been announced on the Gluster mailinglists [1], packages for several distributions should become available in the near future. Keep an eye on the Gluster Users mailinglist [2] and the update infrastructure for your distribution. [1] http://blog.gluster.org/2016/06/glusterfs-3-8-released/ [2] http://thread.gmane.org/gmane.comp.file-systems.gluster.user