diff options
| author | Etienne Dechamps <[email protected]> | 2011-09-05 11:11:38 +0200 |
|---|---|---|
| committer | Brian Behlendorf <[email protected]> | 2012-02-07 16:23:06 -0800 |
| commit | b18019d2d810585185493c62e9567fa85e51692c (patch) | |
| tree | df0d885190bdb964f934576578eee72481449b75 /config | |
| parent | 56c34bac44d47898809c46db3e5444511bbe0ef6 (diff) | |
Fix synchronicity for ZVOLs.
zvol_write() assumes that the write request must be written to stable storage
if rq_is_sync() is true. Unfortunately, this assumption is incorrect. Indeed,
"sync" does *not* mean what we think it means in the context of the Linux
block layer. This is well explained in linux/fs.h:
WRITE: A normal async write. Device will be plugged.
WRITE_SYNC: Synchronous write. Identical to WRITE, but passes down
the hint that someone will be waiting on this IO
shortly.
WRITE_FLUSH: Like WRITE_SYNC but with preceding cache flush.
WRITE_FUA: Like WRITE_SYNC but data is guaranteed to be on
non-volatile media on completion.
In other words, SYNC does not *mean* that the write must be on stable storage
on completion. It just means that someone is waiting on us to complete the
write request. Thus triggering a ZIL commit for each SYNC write request on a
ZVOL is unnecessary and harmful for performance. To make matters worse, ZVOL
users have no way to express that they actually want data to be written to
stable storage, which means the ZIL is broken for ZVOLs.
The request for stable storage is expressed by the FUA flag, so we must
commit the ZIL after the write if the FUA flag is set. In addition, we must
commit the ZIL before the write if the FLUSH flag is set.
Also, we must inform the block layer that we actually support FLUSH and FUA.
Signed-off-by: Brian Behlendorf <[email protected]>
Diffstat (limited to 'config')
| -rw-r--r-- | config/kernel-blk-queue-flush.m4 | 46 | ||||
| -rw-r--r-- | config/kernel.m4 | 1 |
2 files changed, 47 insertions, 0 deletions
diff --git a/config/kernel-blk-queue-flush.m4 b/config/kernel-blk-queue-flush.m4 new file mode 100644 index 000000000..06561edf6 --- /dev/null +++ b/config/kernel-blk-queue-flush.m4 @@ -0,0 +1,46 @@ +dnl # +dnl # 2.6.36 API change +dnl # In 2.6.36 kernels the blk_queue_ordered() interface has been +dnl # replaced by the simpler blk_queue_flush(). However, while the +dnl # old interface was available to all the new one is GPL-only. +dnl # Thus in addition to detecting if this function is available +dnl # we determine if it is GPL-only. If the GPL-only interface is +dnl # there we implement our own compatibility function, otherwise +dnl # we use the function. The hope is that long term this function +dnl # will be opened up. +dnl # +AC_DEFUN([ZFS_AC_KERNEL_BLK_QUEUE_FLUSH], [ + AC_MSG_CHECKING([whether blk_queue_flush() is available]) + tmp_flags="$EXTRA_KCFLAGS" + EXTRA_KCFLAGS="-Wno-unused-but-set-variable" + ZFS_LINUX_TRY_COMPILE([ + #include <linux/blkdev.h> + ],[ + struct request_queue *q = NULL; + (void) blk_queue_flush(q, REQ_FLUSH); + ],[ + AC_MSG_RESULT(yes) + AC_DEFINE(HAVE_BLK_QUEUE_FLUSH, 1, + [blk_queue_flush() is available]) + ],[ + AC_MSG_RESULT(no) + ]) + + AC_MSG_CHECKING([whether blk_queue_flush() is GPL-only]) + ZFS_LINUX_TRY_COMPILE([ + #include <linux/module.h> + #include <linux/blkdev.h> + + MODULE_LICENSE("CDDL"); + ],[ + struct request_queue *q = NULL; + (void) blk_queue_flush(q, REQ_FLUSH); + ],[ + AC_MSG_RESULT(no) + ],[ + AC_MSG_RESULT(yes) + AC_DEFINE(HAVE_BLK_QUEUE_FLUSH_GPL_ONLY, 1, + [blk_queue_flush() is GPL-only]) + ]) + EXTRA_KCFLAGS="$tmp_flags" +]) diff --git a/config/kernel.m4 b/config/kernel.m4 index 10a2cdbcf..a2a819c9b 100644 --- a/config/kernel.m4 +++ b/config/kernel.m4 @@ -21,6 +21,7 @@ AC_DEFUN([ZFS_AC_CONFIG_KERNEL], [ ZFS_AC_KERNEL_BIO_RW_SYNCIO ZFS_AC_KERNEL_REQ_SYNC ZFS_AC_KERNEL_BLK_END_REQUEST + ZFS_AC_KERNEL_BLK_QUEUE_FLUSH ZFS_AC_KERNEL_BLK_FETCH_REQUEST ZFS_AC_KERNEL_BLK_REQUEUE_REQUEST ZFS_AC_KERNEL_BLK_RQ_BYTES |