[Gluster-devel] GlusterFS 3.4.1 planning

[Niels de Vos]

On Fri, Aug 09, 2013 at 05:25:49PM +0100, Nux! wrote:
> On 09.08.2013 11:46, Niels de Vos wrote:
> >On Fri, Aug 09, 2013 at 11:26:06AM +0100, Nux! wrote:
> >>On 09.08.2013 10:23, Vijay Bellur wrote:
> >>>Hi All,
> >>>
> >>>We are considering 3.4.1 to be released in the last week of this
> >>>month. If you are interested in seeing specific bugs addressed or
> >>>patches included in 3.4.1, can you please update them here:
> >>>
> >>>http://www.gluster.org/community/documentation/index.php/Backport_Wishlist
> >>
> >>
> >>Hi, is it too late to open a new bug and hope to see it fixed?
> >>I'm still having problems with Windows nfs clients:
> >>http://www.gluster.org/pipermail/gluster-users/2013-July/036767.html
> >
> >That log suggests that the NFS-client tries to use NFSv2:
> >- RPC program version not available (req 100003 2)
> >  * 100003 is the RPC-program for NFS
> >  * 2 is the version of the program
> >
> >GlusterFS only supports NFSv3 and if you can configure the
> >NFS-client to
> >use version 3 by default, things might go quicker.
> >
> >Googling brought me to
> >http://technet.microsoft.com/en-us/library/cc771204.aspx, but that
> >does
> >not show an option for the version of the NFS protocol to use.
> >There is
> >a suggestion to check with the command 'nfsadmin client /?' for
> >a complete syntax, maybe a NFS version can be specified.
> >
> >I do not have a MS Windows to test or verify, so I can not guide you
> >much more than this.
> >
> >Niels
> 
> When doing Properties on the mounted volume (Z:), it clearly showed
> "version 3", so it looks like it got the right version. It's only
> the browsing related operations that are very slow; file transfers -
> once started - are fast.
> I'll test more when I'm back at work on Monday, maybe see if I can
> force the version from the client.
> Thanks for the input!

Slow browsing could indicate that the NFS-client does not use 
READDIRP(LUS) but only READDIR with a lot of LOOKUP calls.

If you capture a tcpdump and feed it through a recent version of 
wireshark you can get some statistics. When you capture a tcpdump, use 
a command like this

# tcpdump -i any -s 0 -w /tmp/nfs-client.pcap tcp and host $CLIENTIP

  Press CTRL+c to exit the capture.

Gathering statistics with tshark has an interesting commandline:

$ tshark -r nfs-client.pcap -q -z rpc,srt,100003,3

  Note that using rpc,srt,100003,2 would display NFSv2 calls, and you 
  really should not have any of them.

Now, use a more speedy NFS-client and compare the results of a tcpdump 
that contains the same directory browsing. If you are unsure about 
comparing the statistics, post both in a reply to the gluster-devel list 
and one of the guys that knows NFS well should be able to explain (I am 
on holidays next week).

Of course it is possible that the statistics do not show the issue (in 
case the NFS-client is just slow between sending requests or something).  
Other causes can likely be found when comparing the network traces with 
each other, but that's too complex to describe in an email (for now).

Cheers,
Niels