$ sudo tcpdump -i eth0 -n host 10.107.98.211
21:09:28.354879 IP 10.107.98.211.2651514551 > 10.107.98.222.2049: 108 getattr fh Unknown/3A4F474CDDA8283709DB42EBBC8D2B66B649D958377AE2AA604F4859B34149E7
21:09:41.442600 IP 10.107.98.211.2651514551 > 10.107.98.222.2049: 108 getattr fh Unknown/3A4F474CDDA8283709DB42EBBC8D266B649D958377AE2AA604F4859B34149E7
21:10:07.650088 IP 10.107.98.211.2651514551 > 10.107.98.222.2049: 108 getattr fh Unknown/3A4F474CDDA8283709DB42EBBC8D266B649D958377AE2AA604F4859B34149E7
...
Eventually, after 10-15 minutes a response is sent back to the client and NFS works properly again:
21:24:46.352946 IP 10.107.98.222.nfs > 10.107.98.211.892: Flags [S.], seq 1884793786, ack 2118543465, win 14480, options [mss 1460,sackOK,TS val 181785906 ecr 28589184,nop,wscale 7], length 0
Has anyone been successful in implementing something like this using Gluster NFS? I'm not certain if this is an NFS issue (maybe a stale file handle issue) or maybe something related to running NFS using TCP. Or perhaps something else all together. There doesn't seem to be any additional clues either in the client logs or the gluster NFS log.
_______________________________________________ Gluster-users mailing list Gluster-users@xxxxxxxxxxx http://supercolony.gluster.org/mailman/listinfo/gluster-users