NFS - slow

Rick Macklem rmacklem at
Sun Apr 29 21:00:45 UTC 2012

Wojciech Puchar wrote:
> is there any way to speed up NFS server?
> from what i noticed:
> - reads works fast and good, like accessed locally, readahead up to
> maxbsize works fine on large files etc.
> - write works terribly. it performs sync on every write IMHO,
> setting vfs.nfsrv.async=1 improves things SLIGHTLY, but still - writes
> are
> sent to hard disk every single block - no clustering.
> am i doing something wrong or is it that broken?
Since I haven't seen anyone else answer this, I'll throw out my
$0.00 worth one more time. (This topic comes up regularily on the
mailing lists.)

Not broken, it's just a feature of NFS. When the client says FILE_SYNC,
the server is required to do that. (ie. Make sure the data is stored on
stable storage, so it can't be lost if the server crashes/reboots.)
Expensive NFS servers can use non-volatile RAM to speed this up, but a generic
FreeBSD box can't do that.

Some clients (I believe ESXi is one of these) requests FILE_SYNC all the
time, but all clients will do so sooner or later.

If you are exporting ZFS volumes and don't mind violating the NFS RFCs
and risking data loss, there is a ZFS option that helps. I don't use
ZFS, but I think the option is (sync=disabled) or something like that.
(ZFS folks can help out, if you want that.) Even using vfs.nfsrv.async=1
breaks the above.
Once you do this, when an application in a client does a successful
fsync() and assumes the data is safely stored and then the server crashes,
the data can still be lost.

> i tried user space nfs from ports, it's funny but it's performance is
> actually better after i removed fsync from code.
> _______________________________________________
> freebsd-hackers at mailing list
> To unsubscribe, send any mail to
> "freebsd-hackers-unsubscribe at"

More information about the freebsd-hackers mailing list