solaris 11 exercise zfs (2) and intentlog (zil)

sync=standard
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).

sync=always
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.

sync=disabled
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.

Example:

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
real 0m0.482s
user 0m0.003s
sys 0m0.137s

# time for i in 1 2 3 4 ; do cp /tmp/file /rpool/syncstand/file$i; done
real 0m1.035s
user 0m0.003s
sys 0m0.180s

# time for i in 1 2 3 4 ; do cp /tmp/file /rpool/sync/file$i; done
real 0m11.179s
user 0m0.005s
sys 0m0.250s

This entry was posted in Uncategorized. Bookmark the permalink.

Comments are closed.