This is the default option. Synchronous file system transactions
(fsync, O_DSYNC, O_SYNC, etc) are written out (to the intent log)
and then secondly all devices written are flushed to ensure
the data is stable (not cached by device controllers).
For the ultra-cautious, every file system transaction is
written and flushed to stable storage by a system call return.
This obviously has a big performance penalty.
Synchronous requests are disabled. File system transactions
only commit to stable storage on the next DMU transaction group
commit which can be many seconds (5-30sec). This option gives the
highest performance. However, it is very dangerous as ZFS
is ignoring the synchronous transaction demands of
applications such as databases or NFS.
Setting sync=disabled on the currently active root or /var
file system may result in out-of-spec behavior, application data
loss and increased vulnerability to replay attacks.
This option does *NOT* affect ZFS on-disk consistency.
Administrators should only use this when these risks are understood.
1. create a 50M file in /tmp
# dd if=/dev/zero of=/tmp/file bs=1048 count=50000
2. create three filesystems
# zfs create -o sync=disabled rpool/nosync
# zfs create -o sync=standard rpool/syncstand
# zfs create -o sync=always rpool/sync
3. watch performance differences
# time for i in 1 2 3 4 ; do cp /tmp/file /rpool/nosync/file$i; done
# time for i in 1 2 3 4 ; do cp /tmp/file /rpool/syncstand/file$i; done
# time for i in 1 2 3 4 ; do cp /tmp/file /rpool/sync/file$i; done