Date: Sun, 28 Apr 2013 16:58:48 -0400 (EDT) From: Rick Macklem <rmacklem@uoguelph.ca> To: Hiroki Sato <hrs@FreeBSD.org> Cc: freebsd-fs@FreeBSD.org Subject: Re: nfsv3 vs nfsv4 ? advantages of moving to v4? Message-ID: <1097539914.1201151.1367182728935.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20130429.001218.331360293034031466.hrs@allbsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hiroki Sato wrote: > Rick Macklem <rmacklem@uoguelph.ca> wrote > in > <1999055521.1124890.1366849234763.JavaMail.root@erie.cs.uoguelph.ca>: >=20 > rm> Jeremy Chadwick wrote: > rm> > On Wed, Apr 24, 2013 at 04:55:20PM -0700, Marc G. Fournier > wrote: > rm> > > > rm> > > I found this from '11 on Linux: > rm> > > http://archive09.linux.com/feature/138453 > rm> > > > rm> > > their summary is that there isn't any major advantage in > moving to > rm> > > v4, but that was 2 years ago =EF=BF=BD thoughts / opinions ? > rm> > > rm> > Start by reading nfsv4(4). > rm> > > rm> > There are also threads about people seeing immensely decreased > rm> > performance with NFSv4. Not sure if Rick has had the time to > fully > rm> > rectify this (don't let the Subject line fool you): > rm> > > rm> > > http://lists.freebsd.org/pipermail/freebsd-fs/2011-September/012381.html > rm> > > rm> At this point, you can generally assume switching to NFSv4 will be > a performance > rm> hit (or performance neutral at best). If you happen to have a high > end server > rm> (such as a Netapp one that is a cluster that knows how to do > pNFS), > rm> the NFSv4.1 client in head *might* improve performance > rm> beyond what NFSv3 gets from the same server, but as Jeremy noted, > ymmv. > rm> Delegations (and the experimental work in projects/nfsv4-packrats) > may eventually > rm> change that for some environments, as well. (I haven't yet fixed > the "more Lookups > rm> than NFSv3" problem recently identified.) > rm> > rm> The main new features that *might* be a reason for you to adopt > NFSv4 at this time are (imho): > rm> - better support for byte range locking > rm> - NFSv4 ACLs > rm> A couple of others, like referrals and security labels are still > some ways > rm> (maybe a long ways) down the road. >=20 > I need more investigation, but I was trying to use NFSv4 for a while > and noticed that my NFS server's CPU load became much higher and the > performance was worse than NFSv3 though simple microbenchmark showed > no much difference in performance. The degradation seems to depend > on the workload. >=20 Well, someone recently noticed that builds result in far more Lookup operations on the server for NFSv4. I plan on poking at that one to see if I can fix it. There will also be extra overheads for the Open/Close operations, which don't exist on NFSv3 and maintain Windows style oplocks. (The only way to avoid most of these is by enabling delegations.) Beyond that, there has been recent work on reducing cpu overheads for the DRC. This isn't NFSv4 specific, but the patch at: http://people.freebsd.org/~rmacklem/drc4.patch seems to have worked well for testing done by wollman@. Hopefully a refined version of this, using code written by ivoras@ can make it into head in the next few weeks. (I don't know if this patch will be relevent, but the DRC seemed to be the main CPU hog for Garrett Wollman's load and at least a couple of others.) There is also the nfsd thread FH affinity patch that ken@ recently committe= d. Adding NFSv4 support for that is doable, but will take a while. This appare= ntly affects read performance for servers using ZFS (I don't know if CPU usage g= oes up noticably without it?). rick > -- Hiroki
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1097539914.1201151.1367182728935.JavaMail.root>