svn commit: r323535 - vendor-sys/illumos/dist/uts/common/fs/zfs vendor-sys/illumos/dist/uts/common/fs/zfs/sys vendor-sys/illumos/dist/uts/common/sys vendor/illumos/dist/cmd/ztest

Andriy Gapon avg at FreeBSD.org
Wed Sep 13 10:59:39 UTC 2017


Author: avg
Date: Wed Sep 13 10:59:36 2017
New Revision: 323535
URL: https://svnweb.freebsd.org/changeset/base/323535

Log:
  8585 improve batching done in zil_commit()
  
  illumos/illumos-gate at 1271e4b10dfaaed576c08a812f466f6e81370e5e
  https://github.com/illumos/illumos-gate/commit/1271e4b10dfaaed576c08a812f466f6e81370e5e
  
  https://www.illumos.org/issues/8585
    The current implementation of zil_commit() can introduce significant
    latency, beyond what is inherent due to the latency of the underlying
    storage. The additional latency comes from two main problems:
    1. When there's outstanding ZIL blocks being written (i.e. there's
        already a "writer thread" in progress), then any new calls to
        zil_commit() will block waiting for the currently oustanding ZIL
        blocks to complete. The blocks written for each "writer thread" is
        coined a "batch", and there can only ever be a single "batch" being
        written at a time. When a batch is being written, any new ZIL
        transactions will have to wait for the next batch to be written,
        which won't occur until the current batch finishes.
    As a result, the underlying storage may not be used as efficiently
        as possible. While "new" threads enter zil_commit() and are blocked
        waiting for the next batch, it's possible that the underlying
        storage isn't fully utilized by the current batch of ZIL blocks. In
        that case, it'd be better to allow these new threads to generate
        (and issue) a new ZIL block, such that it could be serviced by the
        underlying storage concurrently with the other ZIL blocks that are
        being serviced.
    2. Any call to zil_commit() must wait for all ZIL blocks in its "batch"
        to complete, prior to zil_commit() returning. The size of any given
        batch is proportional to the number of ZIL transaction in the queue
        at the time that the batch starts processing the queue; which
        doesn't occur until the previous batch completes. Thus, if there's a
        lot of transactions in the queue, the batch could be composed of
        many ZIL blocks, and each call to zil_commit() will have to wait for
        all of these writes to complete (even if the thread calling
        zil_commit() only cared about one of the transactions in the batch).
  
  Reviewed by: Brad Lewis <brad.lewis at delphix.com>
  Reviewed by: Matt Ahrens <mahrens at delphix.com>
  Reviewed by: George Wilson <george.wilson at delphix.com>
  Approved by: Dan McDonald <danmcd at joyent.com>
  Author: Prakash Surya <prakash.surya at delphix.com>

Modified:
  vendor/illumos/dist/cmd/ztest/ztest.c

Changes in other areas also in this revision:
Modified:
  vendor-sys/illumos/dist/uts/common/fs/zfs/dmu.c
  vendor-sys/illumos/dist/uts/common/fs/zfs/sys/dmu.h
  vendor-sys/illumos/dist/uts/common/fs/zfs/sys/zil.h
  vendor-sys/illumos/dist/uts/common/fs/zfs/sys/zil_impl.h
  vendor-sys/illumos/dist/uts/common/fs/zfs/sys/zio.h
  vendor-sys/illumos/dist/uts/common/fs/zfs/txg.c
  vendor-sys/illumos/dist/uts/common/fs/zfs/zfs_vnops.c
  vendor-sys/illumos/dist/uts/common/fs/zfs/zil.c
  vendor-sys/illumos/dist/uts/common/fs/zfs/zio.c
  vendor-sys/illumos/dist/uts/common/fs/zfs/zvol.c
  vendor-sys/illumos/dist/uts/common/sys/debug.h

Modified: vendor/illumos/dist/cmd/ztest/ztest.c
==============================================================================
--- vendor/illumos/dist/cmd/ztest/ztest.c	Wed Sep 13 10:57:52 2017	(r323534)
+++ vendor/illumos/dist/cmd/ztest/ztest.c	Wed Sep 13 10:59:36 2017	(r323535)
@@ -1829,13 +1829,14 @@ ztest_get_done(zgd_t *zgd, int error)
 	ztest_object_unlock(zd, object);
 
 	if (error == 0 && zgd->zgd_bp)
-		zil_add_block(zgd->zgd_zilog, zgd->zgd_bp);
+		zil_lwb_add_block(zgd->zgd_lwb, zgd->zgd_bp);
 
 	umem_free(zgd, sizeof (*zgd));
 }
 
 static int
-ztest_get_data(void *arg, lr_write_t *lr, char *buf, zio_t *zio)
+ztest_get_data(void *arg, lr_write_t *lr, char *buf, struct lwb *lwb,
+    zio_t *zio)
 {
 	ztest_ds_t *zd = arg;
 	objset_t *os = zd->zd_os;
@@ -1849,6 +1850,10 @@ ztest_get_data(void *arg, lr_write_t *lr, char *buf, z
 	zgd_t *zgd;
 	int error;
 
+	ASSERT3P(lwb, !=, NULL);
+	ASSERT3P(zio, !=, NULL);
+	ASSERT3U(size, !=, 0);
+
 	ztest_object_lock(zd, object, RL_READER);
 	error = dmu_bonus_hold(os, object, FTAG, &db);
 	if (error) {
@@ -1869,7 +1874,7 @@ ztest_get_data(void *arg, lr_write_t *lr, char *buf, z
 	db = NULL;
 
 	zgd = umem_zalloc(sizeof (*zgd), UMEM_NOFAIL);
-	zgd->zgd_zilog = zd->zd_zilog;
+	zgd->zgd_lwb = lwb;
 	zgd->zgd_private = zd;
 
 	if (buf != NULL) {	/* immediate write */


More information about the svn-src-vendor mailing list