Lines Matching refs:zio
1058 * it's called for "this" lwb (enforced via zio the dependencies
1068 zil_lwb_flush_vdevs_done(zio_t *zio)
1070 lwb_t *lwb = zio->io_private;
1119 zcw->zcw_zio_error = zio->io_error;
1139 * This is called when an lwb's write zio completes. The callback's
1146 * the zio dependencies configured in zil_lwb_set_zio_dependency(),
1148 * once zil_lwb_flush_vdevs_done() is called, which occurs in the zio
1149 * completion callback for the lwb's root zio.
1152 zil_lwb_write_done(zio_t *zio)
1154 lwb_t *lwb = zio->io_private;
1155 spa_t *spa = zio->io_spa;
1164 ASSERT(BP_GET_COMPRESS(zio->io_bp) == ZIO_COMPRESS_OFF);
1165 ASSERT(BP_GET_TYPE(zio->io_bp) == DMU_OT_INTENT_LOG);
1166 ASSERT(BP_GET_LEVEL(zio->io_bp) == 0);
1167 ASSERT(BP_GET_BYTEORDER(zio->io_bp) == ZFS_HOST_BYTEORDER);
1168 ASSERT(!BP_IS_GANG(zio->io_bp));
1169 ASSERT(!BP_IS_HOLE(zio->io_bp));
1170 ASSERT(BP_GET_FILL(zio->io_bp) == 0);
1172 abd_put(zio->io_abd);
1191 if (zio->io_error != 0) {
1236 * lwb/zio dependency chain, which is used to preserve the
1238 * of the ZIL. Each new lwb zio becomes a parent of the
1239 * "previous" lwb zio, such that the new lwb's zio cannot
1240 * complete until the "previous" lwb's zio completes.
1243 * waiters attached to the lwbs will be woken in the lwb zio's
1244 * completion callback, so this zio dependency graph ensures the
1270 * this ordering by setting the zio parent/child
1273 * Without this relationship on the lwb's write zio,
1278 * vdevs are flushed in the lwb write zio's completion
1295 * accept new itxs being committed to it. To do this, the lwb's zio
1653 * becomes the parent of any zio's created by
1657 * callback waits for these additional zio's,
1658 * such that the vdevs used by those zio's will
1662 * vdevs may not be flushed; e.g. if these zio's
2149 * lwb will be issued to the zio layer to be written to disk.
2288 * it, so there's no point in issuing its zio (i.e.
2294 * the lwb's zio to disk yet, and instead rely on one of
2295 * the following two mechanisms for issuing the zio:
2300 * thread) and this lwb's zio will be issued via
2306 * the system, such that this lwb's zio isn't issued via
2308 * lwb's zio. If this occurs, the lwb is not guaranteed
2309 * to be "full" by the time its zio is issued, and means
2458 * zil_process_commit_list(), we need to issue this lwb's zio
2467 * Since the lwb's zio hadn't been issued by the time this thread
2471 * By having to issue the lwb's zio here, it means the size of the
2497 * lwb's zio callback to call dmu_tx_commit().
2499 * - The lwb's zio callback can't call dmu_tx_commit()
2519 * 2. its secondary responsibility is to issue the zio for the lwb that
2524 * the ZIL, the lwb's zio will be issued via the zil_lwb_commit()
2703 * by the itx is copied into the lwb's zio buffer, and once this buffer
2746 * commit waiters, and zio completion callbacks like we're doing:
2749 * waiter is marked "done" and signalled, in the zio completion
2750 * callback of the lwb's zio[*].
2752 * * Actually, the waiters are signalled in the zio completion
2753 * callback of the root zio for the DKIOCFLUSHWRITECACHE commands
2754 * that are sent to the vdevs upon completion of the lwb zio.
2792 * To enforce this ordering of lwb zio's, while still leveraging as
2796 * 1. The creation and issuance of lwb zio's is protected by
2800 * (leveraging the zio parent-child depenency graph)
2802 * By relying on this parent-child zio relationship, we can have
2803 * many lwb zio's concurrently issued to the underlying storage,