search for: libnbd_cmd_flag_no_hole

...he C<flags> parameter may be C<0> for no flags, or may contain C<LIBNBD_CMD_FLAG_FUA> meaning that the server should not return until the data has been committed to permanent storage (if that is supported - some servers cannot do this, see -L<nbd_can_fua(3)>), and/or C<LIBNBD_CMD_FLAG_NO_HOLE> meaning that +L<nbd_can_fua(3)>), C<LIBNBD_CMD_FLAG_NO_HOLE> meaning that the server should favor writing actual allocated zeroes over -punching a hole."; +punching a hole, and/or C<LIBNBD_CMD_FLAG_FAST_ZERO> meaning +that the server must fail quickly if writing zeroes i...

...set_error (EINVAL, "server does not support zero operations"); + return -1; + } + if (nbd_unlocked_is_read_only (h) == 1) { + set_error (EPERM, "server does not support write operations"); + return -1; + } - if ((flags & ~(LIBNBD_CMD_FLAG_FUA | LIBNBD_CMD_FLAG_NO_HOLE | - LIBNBD_CMD_FLAG_FAST_ZERO)) != 0) { - set_error (EINVAL, "invalid flag: %" PRIu32, flags); - return -1; - } + if ((flags & ~(LIBNBD_CMD_FLAG_FUA | LIBNBD_CMD_FLAG_NO_HOLE | + LIBNBD_CMD_FLAG_FAST_ZERO)) != 0) { + set_error (EINVAL,...

We have been inconsistent on how much we reject client-side without even consulting the server, vs. how much we depend on the server to detect failure (even if our request can be deemed undefined per NBD protocol). I'd like to change it so that by default, we reject as much as we can client-side for less traffic, but where the user can also change things on the fly for server-side integration

I'm not observing any noticeable performance differences, but I'm liking the diffstat. I can't push this patch until we release a new libnbd version with the _notify API addition, but am posting it now for playing with things. Eric Blake (2): nbd: Move transaction info from heap to stack nbd: Use nbdkit aio_*_notify variants plugins/nbd/nbd.c | 217

...SET_CALLBACK_TO_NULL (*completion); return nbd_internal_command_common (h, 0, NBD_CMD_CACHE, offset, count, NULL, &cb); @@ -454,12 +420,6 @@ nbd_unlocked_aio_zero (struct nbd_handle *h, return -1; } - if ((flags & ~(LIBNBD_CMD_FLAG_FUA | LIBNBD_CMD_FLAG_NO_HOLE | - LIBNBD_CMD_FLAG_FAST_ZERO)) != 0) { - set_error (EINVAL, "invalid flag: %" PRIu32, flags); - return -1; - } - if ((flags & LIBNBD_CMD_FLAG_FUA) != 0 && nbd_unlocked_can_fua (h) != 1) { set_error (EINVAL, "server does not support t...

This is a cover letter to a series of patches being proposed in tandem to four different projects: - nbd: Document a new NBD_CMD_FLAG_FAST_ZERO command flag - qemu: Implement the flag for both clients and server - libnbd: Implement the flag for clients - nbdkit: Implement the flag for servers, including the nbd passthrough client If you want to test the patches together, I've pushed a

...t32_t flags) struct transaction s; uint32_t f = 0; - assert (!(flags & ~(NBDKIT_FLAG_FUA | NBDKIT_FLAG_MAY_TRIM))); + assert (!(flags & ~(NBDKIT_FLAG_FUA | NBDKIT_FLAG_MAY_TRIM | + NBDKIT_FLAG_FAST_ZERO))); if (!(flags & NBDKIT_FLAG_MAY_TRIM)) f |= LIBNBD_CMD_FLAG_NO_HOLE; if (flags & NBDKIT_FLAG_FUA) f |= LIBNBD_CMD_FLAG_FUA; +#if LIBNBD_HAVE_NBD_CAN_FAST_ZERO + if (flags & NBDKIT_FLAG_FAST_ZERO) + f |= LIBNBD_CMD_FLAG_FAST_ZERO; +#else + assert (!(flags & NBDKIT_FLAG_FAST_ZERO)); +#endif nbdplug_prepare (&s); nbdplug_register (h,...

...(void *handle, uint32_t count, uint64_t offset, uint32_t flags) uint32_t f = 0; assert (!(flags & ~(NBDKIT_FLAG_FUA | NBDKIT_FLAG_MAY_TRIM))); - assert (h->flags & NBD_FLAG_SEND_WRITE_ZEROES); if (!(flags & NBDKIT_FLAG_MAY_TRIM)) - f |= NBD_CMD_FLAG_NO_HOLE; + f |= LIBNBD_CMD_FLAG_NO_HOLE; if (flags & NBDKIT_FLAG_FUA) - f |= NBD_CMD_FLAG_FUA; - s = nbdplug_request (h, f, NBD_CMD_WRITE_ZEROES, offset, count); + f |= LIBNBD_CMD_FLAG_FUA; + s = nbdplug_register (h, nbd_aio_zero (h->nbd, count, offset, f)); return nbdplug_reply (h, s); } @@ -1285,10 +660,10 @@ nbd...

...(void *handle, uint32_t count, uint64_t offset, uint32_t flags) uint32_t f = 0; assert (!(flags & ~(NBDKIT_FLAG_FUA | NBDKIT_FLAG_MAY_TRIM))); - assert (h->flags & NBD_FLAG_SEND_WRITE_ZEROES); if (!(flags & NBDKIT_FLAG_MAY_TRIM)) - f |= NBD_CMD_FLAG_NO_HOLE; + f |= LIBNBD_CMD_FLAG_NO_HOLE; if (flags & NBDKIT_FLAG_FUA) - f |= NBD_CMD_FLAG_FUA; - s = nbdplug_request (h, f, NBD_CMD_WRITE_ZEROES, offset, count); + f |= LIBNBD_CMD_FLAG_FUA; + s = nbdplug_register (h, nbd_aio_zero (h->nbd, count, offset, f)); return nbdplug_reply (h, s); } @@ -1290,10 +647,10 @@ nbd...

In v2: - now based on my proposal to add LIBNBD_SHUTDOWN_IMMEDIATE - four flags instead of two: STRICT_FLAGS is new (patch 4), and STRICT_BOUNDS is separate from STRICT_ZERO_SIZE (patch 5) - various refactorings for more shared code and less duplication Eric Blake (5): api: Add xxx_MASK constant for each Flags type generator: Refactor filtering of accepted OFlags api: Add

Patch 1 played with an early draft of Rich's Fedora 30 libnbd package: https://bugzilla.redhat.com/show_bug.cgi?id=1713767#c17 Note that comment 21 provides a newer package 0.1.1-1 with a different API; and that libnbd has more unreleased API changes in the pipeline (whether that will be called 0.2 or 0.1.2); so we'll have to tweak things based on what is actually available in distros.

libnbd-0.1.2-1 is now available in Fedora 29/30 updates-testing, although it was not compiled against libxml2 so it lacks uri support (I ended up testing patch 4 with a self-built libnbd). Diffs since v1 - rebase to master, bump from libnbd 0.1 to 0.1.2, add URI support, better timing results Still not done - patch 5 needs associated tests Eric Blake (5): nbd: Check for libnbd nbd:

libnbd-0.1.4-1 is now available in Fedora 29/30 updates testing. Diffs since v2 - rebase to master, bump from libnbd 0.1.2 to 0.1.3+, add tests to TLS usage which flushed out the need to turn relative pathnames into absolute, doc tweaks Now that the testsuite covers TLS and libnbd has been fixed to provide the things I found lacking when developing v2, I'm leaning towards pushing this on