Description of problem: When we mount rdma only volume or tcp,rdma volume using newly peer probed IP's(nfs-server on new nodes) through nfs protocol , mount fails for rdma only volume and mount happens with help of tcp in tcp,rdma volumes. How reproducible: Always Steps to Reproduce: 1.Create a rdma only or tcp,rdma volumes in the cluster 2.Start the volume 3.Peer Probe a new server 4.Try to mount using new nfs-server (new IP) Actual results: 1. For rdma only volume , mount fails 2. For tcp,rdma volume , mount happens with help of tcp Expected results: 1.mount should happen incase of rdma only volume 2.mount should happen with rdma transport type by default if no options are set for nfs.transport-type incase of tcp,rdma volume Additional info: nfs-server-volgraph build on newly added server is always contains transport type as tcp(socket).
REVIEW: http://review.gluster.org/9172 (rdma :mount fails for nfs protocol in rdma volumes) posted (#1) for review on release-3.6 by jiffin tony Thottan (jthottan)
COMMIT: http://review.gluster.org/9172 committed in release-3.6 by Raghavendra Bhat (raghavendra) ------ commit c01581c92e1fac7603ff7e040053c5e40afbc924 Author: Jiffin Tony Thottan <jthottan> Date: Fri Nov 21 11:48:46 2014 +0530 rdma :mount fails for nfs protocol in rdma volumes When we mount rdma only volume or tcp,rdma volume using newly peer probed IP's(nfs-server on new nodes) through nfs protocol, mount fails for rdma only volume and mount happens with help of tcp protocol in the case of tcp,rdma volumes. That is for newly added servers will always get transport type as "socket". This is due to nfs_transport_type is exported correctly and imported wrongly. This can be verified by the following , * Create a rdma only volume or tcp,rdma volume * Add a new server into the trusted pool. * Checkout the client transport type specified nfs-server volgraph.It will be always tcp(socket type) instead of rdma. * And also for rdma only volume in the nfs log, we can see 'connection refused' message for every reconnect between nfs server and glusterfsd. Backport of http://review.gluster.org/8975 cherry picked from commit f380e2029d608f97e3ba9a728605e1d798b09e8d >BUG: 1157381 >Change-Id: I6bd4979e31adfc72af92c1da06a332557b6289e2 >Author: Jiffin Tony Thottan <jthottan> >Signed-off-by: Jiffin Tony Thottan <jthottan> >Reviewed-on: http://review.gluster.org/8975 >Reviewed-by: Meghana M <mmadhusu> >Reviewed-by: Atin Mukherjee <amukherj> >Reviewed-by: Niels de Vos <ndevos> >Tested-by: Niels de Vos <ndevos> Change-Id: I328c17b07e877fe3b29ca832bf6f2291cea16bbe BUG: 1166505 Reviewed-on: http://review.gluster.org/9172 Tested-by: Gluster Build System <jenkins.com> Reviewed-by: soumya k <skoduri> Reviewed-by: Raghavendra Bhat <raghavendra>
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.6.2, please reopen this bug report. glusterfs-3.6.2 has been announced on the Gluster Developers mailinglist [1], packages for several distributions should already be or become available in the near future. Keep an eye on the Gluster Users mailinglist [2] and the update infrastructure for your distribution. The fix for this bug likely to be included in all future GlusterFS releases i.e. release > 3.6.2. [1] http://thread.gmane.org/gmane.comp.file-systems.gluster.devel/5978 [2] http://news.gmane.org/gmane.comp.file-systems.gluster.user [3] http://thread.gmane.org/gmane.comp.file-systems.gluster.devel/6137