It's a relatively well known issue that writing lots of small files overNFS to a ZFS filesystem is slow, but I was surprised to discover that ithad a significant slowdown even when doing large bulk streaming writesto single files. Discovering this got me curious enough to dig intothings.

Like most recent filesystems, ZFS is a journaled, usingwhat the ZFS people call the ZIL (ZFS Intent Log) .Also like other journaled filesystems, ZFS has the fsyncproblem . So where do the syncscome from

Consider your ordinary journaling filesystem. For simplicity andreliability you have a single, global log in which you put transactionsfor all of your filesystem activity, instead of anything morecomplicated. One useful consequence of this global log is that you havenow created a filesystem-wide global order of all filesystem events(sometimes called a 'total order'), which will be preserved even ifyou crash and restart.

(You implicitly had a total order before, but it didn't necessarilysurvive crashes.)

This sounds

Modern versions of NFS have a variety of authentication methods, andso one of the errors that a NFS server can give a client is 'yourauthentication method is too weak'; for example, the client couldbe sending plain old Unix UIDs and GIDs to a server that requiresKerberos to get strong distributed filesystem authentication . When this happens, the Linux kernelhelpfully prints an error message about it:

call_verify: server somehost.cs requires stronger authentication.

In fact, it prints this message every time it gets