Re: file xfer over NFSv4 with 'sync' ~300X slower than with 'async' ?

["J. Bruce Fields" <bfields@fieldses.org>]

On Wed, Apr 01, 2015 at 02:59:48PM -0400, Trond Myklebust wrote:
> On Wed, Apr 1, 2015 at 2:51 PM, J. Bruce Fields <bfields@fieldses.org> wrote:
> > On Wed, Apr 01, 2015 at 11:02:17AM -0700, lyndat3@your-mail.com wrote:
> >> > There's no maximum sync/async ratio.  You could make that ratio lower or
> >> > higher by varying dd's block size, for example.
> >> >
> >> > The way I'd look at it, your dd of a 100MB file above is doing 3072
> >> > writes, and taking about 8*60/3072 =~ .16 seconds per write.
> >> >
> >> > That does sound high.  Things to look at to understand why might include
> >> > the round-trip ping time to the server, and the time for the server's
> >> > disk to do a synchronous write.
> >> >
> >>
> >> After comments from one of the nfs client maintainers, it turns out the slowness issue is simply one of not-quite-MIS-configuration.
> >>
> >> As helpfully commented here
> >>
> >>   http://serverfault.com/questions/499174/etc-exports-mount-option/500553#500553
> >>
> >> , IIUC there are two *separate* syncs to consider -- at the server, and at the client.
> >>
> >> 'sync' on the EXPORT, and 'async' on the MOUNT is the sane approach; That config also appears to return the performance.
> >>
> >> The many recommendations online to use 'sync' for data integrity are IIUC for sync on the server.
> >
> > Yes.  This is a common source of confusion.  In retrospect maybe the
> > export sync/async option should have had a different name from the
> > client mount option.--b.
> >
> 
> Do we still need a server 'async' export option? Who is still using
> NFSv2 for any type of performance-critical work?

It also bypasses commits on metadata operations.  Not that that makes it
a good idea, but it could still easily make a noticeable difference.

--b.