ZFSv28+NFSv4 poor file creation performance, "sync=disabled" has no effect

[David Brodbeck]

On Fri, Sep 2, 2011 at 6:36 PM, Rick Macklem <rmacklem at uoguelph.ca> wrote:

> One post explained how disabling the ZIL can result in up to 5seconds worth
> of changes being lost if/when the server crashes. (A lot can change on a
> file
> system in 5sec. The NFS protocol assumes all fs changes related to a file
> creation are done before the server replies to the RPC. As such, disabling
> the
> ZIL does violate the protocol specs and means you are living dangerously.)
>

Yes, I'm aware of that.  I chose to take that risk in my configuration
because we frequently extract large tarballs, and performance with the
default settings is not acceptable.  Also, most other filesystems make no
guarantees that data has been flushed to the platters, only that it's been
sent to the disk hardware, so it really isn't a big increase in risk
compared to our pre-ZFS setup.

The sync=disabled parameter was, in my understanding, added as a
per-filesystem way to achieve this risk/performance tradeoff, instead of
zil_disable, which was system-wide.  I posted the question because I'm not
seeing any changes when I use sync=disabled.

This is a bit of a show-stopper for us because performance with full syncing
is not acceptable. I agree that it's not ideal, but we don't have the extra
drive bays to add SSDs at this point; also it seems like people have had a
lot of problems with SSDs and FreeBSD, so I'd prefer for the technology to
mature a bit before I risk my entire pool by putting a ZIL on one.

-- 
David Brodbeck
System Administrator, Linguistics
University of Washington