Red Hat Bugzilla – Bug 1255365
Enabling or disabling USS restarts NFS server process on all nodes
Last modified: 2016-02-18 05:51:52 EST
Description of problem:
1)if user enables/disables USS on a volume, the NFS server process are restarted on all the brick nodes.
This is not really a feature of high available filesystem.
I have seen that after uss is enabled and while we mount a volume using NFS and access .snaps, if we turn off uss and enable again, user needs to come out of the mount path and again get into the mount path to access .snaps
Version-Release number of selected component (if applicable):
[root@localhost ~]# gluster --version
glusterfs 3.7.1 built on Jul 19 2015 02:16:06
Repository revision: git://git.gluster.com/glusterfs.git
Copyright (c) 2006-2011 Gluster Inc. <http://www.gluster.com>
GlusterFS comes with ABSOLUTELY NO WARRANTY.
You may redistribute copies of GlusterFS under the terms of the GNU General Public License.
[root@localhost ~]# cat /etc/redhat-*
Red Hat Enterprise Linux Server release 7.1 (Maipo)
Red Hat Gluster Storage Server 3.1
[root@localhost ~]# rpm -qa|grep gluster
Steps to Reproduce:
1.create a volume and a snapshot
2. using vol status note down the nfs server processes
3)turn on uss
4)now again issue vol status, it can be seen nfs PIDs would have changed(nfs is killed and restarted)
5)now from nfs mount access .snaps folder and view files in the above created snapshot
6)now turn off and turn on uss
7)It can be seen that .snaps is not accessible anymore
8)user has to again come out and enter the path to reaccess .snaps
Do you have a tcpdump and/or output from rpcdebug taken on the NFS-client when this happens?
I'd also like to know if this only happens with NFS, or also with FUSE mountpoints.
Maybe you should test it out by disabling nfs-client caching (using mount option noac). It is by design that gluster-nfs restarts whenever there is change in volfile (which includes enabling uss). Considering that gluster-nfs shall be deprecated sooner, re-designing it doesn't make much sense unless the expected behaviour is not achieved by using alternate solution (which is to use nfs-ganesha). Closing it.
I think it should be easily reproducible. I don't have a statedump for this