From e98b6117252acb4931bbcc0ff6b164269273de4e Mon Sep 17 00:00:00 2001 From: Andriy Gapon Date: Mon, 17 Jul 2017 15:31:30 +0300 Subject: [PATCH] OpenZFS 8373 - TXG_WAIT in ZIL commit path Authored by: Andriy Gapon Reviewed by: Prakash Surya Reviewed by: Matthew Ahrens Approved by: Dan McDonald Reviewed-by: George Melikov Reviewed-by: Brian Behlendorf Ported-by: Giuseppe Di Natale OpenZFS-issue: https://www.illumos.org/issues/8373 OpenZFS-commit: https://github.com/openzfs/openzfs/commit/7f04961 Closes #6403 --- module/zfs/zil.c | 19 ++++++++++++++++++- 1 file changed, 18 insertions(+), 1 deletion(-) diff --git a/module/zfs/zil.c b/module/zfs/zil.c index 6a1f190f5..6b0346893 100644 --- a/module/zfs/zil.c +++ b/module/zfs/zil.c @@ -1009,7 +1009,24 @@ zil_lwb_write_start(zilog_t *zilog, lwb_t *lwb) * to clean up in the event of allocation failure or I/O failure. */ tx = dmu_tx_create(zilog->zl_os); - VERIFY(dmu_tx_assign(tx, TXG_WAIT) == 0); + + /* + * Since we are not going to create any new dirty data and we can even + * help with clearing the existing dirty data, we should not be subject + * to the dirty data based delays. + * We (ab)use TXG_WAITED to bypass the delay mechanism. + * One side effect from using TXG_WAITED is that dmu_tx_assign() can + * fail if the pool is suspended. Those are dramatic circumstances, + * so we return NULL to signal that the normal ZIL processing is not + * possible and txg_wait_synced() should be used to ensure that the data + * is on disk. + */ + error = dmu_tx_assign(tx, TXG_WAITED); + if (error != 0) { + ASSERT3S(error, ==, EIO); + dmu_tx_abort(tx); + return (NULL); + } dsl_dataset_dirty(dmu_objset_ds(zilog->zl_os), tx); txg = dmu_tx_get_txg(tx);