search for: libnbd_cmd_flag_fast_zero

...tion; }; + "can_fast_zero", { + default_call with + args = []; ret = RBool; + permitted_states = [ Connected; Closed ]; + shortdesc = "does the server support the fast zero flag?"; + longdesc = "\ +Returns true if the server supports the use of the +C<LIBNBD_CMD_FLAG_FAST_ZERO> flag to the zero command +(see C<nbd_zero>, C<nbd_aio_zero>). Returns false if +the server does not." +^ non_blocking_test_call_description; + }; + "can_df", { default_call with args = []; ret = RBool; @@ -1668,9 +1682,12 @@ The C<flags> parameter...

...t 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, "invalid flag: %" PRIu32, flags); +...

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

...e or L<nbd_is_read_only(3)> is true. The C<flags> parameter may be C<0> for no flags, or may contain C<LIBNBD_CMD_FLAG_FUA> meaning that the server should not @@ -1731,9 +1806,11 @@ the server should favor writing actual allocated zeroes over punching a hole, and/or C<LIBNBD_CMD_FLAG_FAST_ZERO> meaning that the server must fail quickly if writing zeroes is no faster than a normal write (if that is supported - some servers -cannot do this, see L<nbd_can_fast_zero(3)>)."; - see_also = [Link "can_fua"; Link "can_zero"; - Link "can_f...

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

...urn 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 the FUA flag"); @@ -504,11 +464,6 @@ nbd_u...

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

..._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, &s, nbd_aio_zero (h->nbd, count, offset, s.cb, f)); return nbdplug_reply (h, &s); @@ -831,6 +856,7 @@ static struct nbdkit_plugin plugin = { .is_rotational =...

This replaces 13/13 of my v2 series; and now that it has pretty good testsuite coverage and demonstrable performance improvement to nbdinfo, I'm going ahead and pushing this now. We may still want to add further nbd_opt_* commands for other fine-grained tuning of negotiation, but for now, I think things have stabilized on this end, and I can return to polishing .list_exports on the nbdkit

Well, I'm not quite done (I still want to get nbdinfo to work on a single nbd connection for all cases when reading the heads of the file is not required), but I'm happy with patches 1-11, and 12-13 show where I'm headed for getting NBD_OPT_INFO to work. Posting now to see if some of the earlier patches are ready to commit while I continue working on the latter half. Eric Blake (13):