sync vs async vs zfs

[Paul Kraus]

On Sep 24, 2015, at 22:05, Quartz <quartz at sneakertech.com> wrote:

>> I expect that system utilities like cp and tar do not do sync writes.
>> sync writes are supposed to be a special case, used only when needed.
>> I run into them with VBox writing to<>.vmdk files.
> 
> NFS forces sync though, doesn't it? What if you're cp-ing to a mounted share? I'm not sure I totally understand how all this interacts.

Reading the NFS ver 3 RFC (1813, available here: https://tools.ietf.org/html/rfc1813, look for the descriptions of the WRITE and COMMIT procedures), it looks like NFS ver 2 was sync only, while ver 3 added the ability (at the protocol layer) to require sync data, sync data + metadata, or async behavior. From some Linux NFS notes I found it appears that the default Linux behavior is sync, but you can disable sync on the server side (as you can with ZFS) in which case the NFS server does not follow the protocol specification.

From the FreeBSD man page options for mount_nfs:
	wcommitsize=<value>
		     Set the maximum pending write commit size to the speci-
		     fied value.  This determines the maximum amount of	pend-
		     ing write data that the NFS client	is willing to cache
		     for each file.

This implies that the FreeBSD NFS client fully implements the ver 3 protocol which permits the client to cache data until an fsync call is made or the amount of data in the client cache reaches “wcommitsize”. Essentially, async behavior.

It does not look like (from reading the exports man page) you can disable handling of sync data, sync data + metadata, or async on the NFS server side. In other words, the FreeBSD NFS server does what the client instructs it, as it should to comply with the NFS Ver 3 specification in the RFC.

>>> 2) Async doesn't really care how your pool is constructed, and a
>>> SLOG is really the only thing that seriously makes a difference for
>>> sync, correct?
>> 
>> Not quite true. Once you get through the ARC the configuration of the
>> zpool _will_ matter to performance.
> 
> Maybe I worded that badly. What I meant was that whereas sync write performance is strongly affected by a SLOG, async writes have no special considerations of their own that don't also affect sync, right?

Correct. Any configuration change that effects async performance will effect sync performance as well. While the ZIL/SLOG can effect sync performance, they are not involved in async writer operations at all, so cannot have nay effect on sync writes.

Although, I suppose you _could_ say that an increase in the amount of RAM available for the ARC may increase async write performance, such an increase in ARC would have little to no effect on sync writes. While sync writes _do_ go through the ARC, the ZIL/SLOG insulates the App trying to write the data from that.

--
Paul Kraus
paul at kraus-haus.org