search for: can_fast_zero

...write fallback; nbd takes advantage of libnbd extensions proposed in parallel to pass through support; and v2 language bindings expose the choice to their scripts. The testsuite is updated thanks to the sh plugin to cover this. In turn, the sh plugin has to be a bit smarter about handling missing can_fast_zero to get decent fallback support from nbdkit. Plugins untouched by this patch either do not support .zero with flags (including v1 plugins; these are all okay with the default behavior of advertising but always failing fast zeroes), or are too difficult to analyze in this patch (so not advertising i...

...ed Hat Inc. + * Copyright (C) 2014-2020 Red Hat Inc. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions are @@ -98,6 +98,8 @@ type 'a plugin = { thread_model : (unit -> thread_model) option; can_fast_zero : ('a -> bool) option; + + preconnect : (bool -> unit) option; } let default_callbacks = { @@ -145,6 +147,8 @@ let default_callbacks = { thread_model = None; can_fast_zero = None; + + preconnect = None; } external set_name : string -> unit = "ocaml_nbdkit_set_name&q...

...isk only once (more transactions, but no time lost to duplicated I/O due to slow zeroes). As such, the NBD protocol is adding an extension to allow clients to request fast failure when zero is not efficient, from servers that advertise support for the new flag. In nbdkit, start by plumbing a new .can_fast_zero through the backends (although it stays 0 in this patch, later patches will actually expose it to plugins and filters to override). Advertise the flag to the client when the plugin provides a .can_fast_zero, and wire in passing the flag down to .zero in the plugin. In turn, if the flag is set and...

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

On 3/18/20 8:21 PM, Eric Blake wrote: > In commit c306fa93ab and neighbors (v1.15.1), a concerted effort went > into caching the results of .can_FOO callbacks, with commit messages > demonstrating that a plugin with a slow callback should not have that > delay magnified multiple times. But nothing was added to the > testsuite at the time, and with the sh and eval plugins, we still

...onn', False) + +def can_write (h): + return cfg.get ('can_write', True) + +def can_flush(h): + return cfg.get ('can_flush', False) + +def can_trim(h): + return cfg.get ('can_trim', False) + +def can_zero(h): + return cfg.get ('can_zero', False) + +def can_fast_zero(h): + return cfg.get ('can_fast_zero', False) + +def can_fua(h): + fua = cfg.get ('can_fua', "none") + if fua == "none": + return nbdkit.FUA_NONE + elif fua == "emulate": + return nbdkit.FUA_EMULATE + elif fua == "nativ...

v3 was here: https://www.redhat.com/archives/libguestfs/2019-November/msg00209.html In v4: - Rebase on top of current master. Includes various fixes and updates required because of Nir's patches that went into master. - Fix api_version() -> API_VERSION in patch 2 noted previously on the mailing list. Rich.

v1: https://www.redhat.com/archives/libguestfs/2019-November/msg00153.html v2: - Fix implementation of can_cache. - Add implementation of can_fua. - Add a very thorough test suite which tests every command + flag combination.

...cache ? "true" : "false"); if (can_df >= 0) - printf ("\t%s: %s\n", "can_df", can_df ? "true" : "false"); + fprintf (fp, "\t%s: %s\n", "can_df", can_df ? "true" : "false"); if (can_fast_zero >= 0) - printf ("\t%s: %s\n", "can_fast_zero", can_fast_zero ? "true" : "false"); + fprintf (fp, "\t%s: %s\n", "can_fast_zero", + can_fast_zero ? "true" : "false"); if (can_flush >= 0)...

v2 was here: https://www.redhat.com/archives/libguestfs/2019-November/msg00163.html I pushed patch 1 (with spelling fix), patch 4 and patch 5 since those were previously ACKed on the list. Differences in v3: - Add error checking to PyModule_AddIntConstant. - Use API_VERSION constant instead of function. - Add max API version supported to --dump-plugin output. - Print API_VERSION selected by

...get ('can_write', True) > + > +def can_flush(h): > + return cfg.get ('can_flush', False) > + > +def can_trim(h): > + return cfg.get ('can_trim', False) > + > +def can_zero(h): > + return cfg.get ('can_zero', False) > + > +def can_fast_zero(h): > + return cfg.get ('can_fast_zero', False) > + > +def can_fua(h): > + fua = cfg.get ('can_fua', "none") > + if fua == "none": > + return nbdkit.FUA_NONE > + elif fua == "emulate": > + return nbdkit....

...backend_plugin *p = container_of (b, struct backend_plugin, backend); if (p->plugin.can_trim) - return p->plugin.can_trim (handle); + return normalize_bool (p->plugin.can_trim (handle)); else return p->plugin.trim || p->plugin._trim_v1; } @@ -380,7 +388,7 @@ plugin_can_fast_zero (struct backend *b, void *handle) int r; if (p->plugin.can_fast_zero) - return p->plugin.can_fast_zero (handle); + return normalize_bool (p->plugin.can_fast_zero (handle)); /* Advertise support for fast zeroes if no .zero or .can_zero is * false: in those cases, we fail...

...no time lost to duplicated I/O due to slow zeroes). As such, the NBD protocol is adding an extension to allow clients to request fast failure when zero is not efficient, from servers that advertise support for the new flag. In libnbd, this results in the addition of a new flag, a new functoin nbd_can_fast_zero, and the ability to use the new flag in nbd_zero variants. It also enhances the testsuite to test the flag against new enough nbdkit, which is being patched at the same time. Signed-off-by: Eric Blake <eblake@redhat.com> --- lib/nbd-protocol.h | 2 ++ generator/generator | 29 +++++...

.../libguestfs/2018-April/msg00108.html Note that with my proposal, there is no need for a python script to expose a global API_VERSION variable; new flags are added using a Python API that is backwards-compatible. In fact, with introspection, we can even get away with the user not having to write a can_fast_zero; the mere presence of support for a fast=... kw parameter is enough to let us pick the correct default. However, there are aspects of Rich's proposal that I like better: for example, by having an explicit API_VERSION variable, we can change the interface of pread to read directly into a buffer...

...e rest of the next ops are the same as normal plugin operations. */ - int64_t (*get_size) (void *nxdata); - - int (*can_write) (void *nxdata); - int (*can_flush) (void *nxdata); - int (*is_rotational) (void *nxdata); - int (*can_trim) (void *nxdata); - int (*can_zero) (void *nxdata); - int (*can_fast_zero) (void *nxdata); - int (*can_extents) (void *nxdata); - int (*can_fua) (void *nxdata); - int (*can_multi_conn) (void *nxdata); - int (*can_cache) (void *nxdata); - - int (*pread) (void *nxdata, void *buf, uint32_t count, uint64_t offset, + int64_t (*get_size) (backend *nxdata); + + int (*can...

...uct backend_plugin, backend); > > if (p->plugin.can_trim) > - return p->plugin.can_trim (handle); > + return normalize_bool (p->plugin.can_trim (handle)); > else > return p->plugin.trim || p->plugin._trim_v1; > } > @@ -380,7 +388,7 @@ plugin_can_fast_zero (struct backend *b, void *handle) > int r; > > if (p->plugin.can_fast_zero) > - return p->plugin.can_fast_zero (handle); > + return normalize_bool (p->plugin.can_fast_zero (handle)); > /* Advertise support for fast zeroes if no .zero or .can_zero is >...

I still don't have .prepare/.finalize working cleanly across reopen, but did find a nasty bug where a botched assertion means we failed to notice reads beyond EOF in both the xz and retry filter. Refactoring backend.c will make .finalize work easier. Eric Blake (5): xz: Avoid reading beyond EOF retry: Check size before transactions tests: Test retry when get_size values change

....open = cc_open, + .close = cc_close, - .get_size = cc_get_size, - .can_write = cc_can_write, - .can_flush = cc_can_flush, - .is_rotational = cc_is_rotational, - .can_trim = cc_can_trim, - .can_zero = cc_can_zero, - .can_fast_zero = cc_can_fast_zero, - .can_extents = cc_can_extents, - .can_fua = cc_can_fua, - .can_multi_conn = cc_can_multi_conn, - .can_cache = cc_can_cache, + .export_description = cc_export_description, + .get_size = cc_get_size, + .can_write = cc_can_...

...to do more testing and/or kernel source code reading to learn whether to mark fallocate() as potentially slow, as well as to definitely mark ioctl(BLKZEROOUT) as definitely slow. That will be a followup patch. Eric Blake (3): server: Add internal support for NBDKIT_FLAG_FAST_ZERO filters: Add .can_fast_zero hook plugins: Add .can_fast_zero hook docs/nbdkit-filter.pod | 27 ++++-- docs/nbdkit-plugin.pod | 74 +++++++++++--- docs/nbdkit-protocol.pod | 11 +++ filters/delay/nbdkit-delay-filter.pod | 15 ++- filters/log/nbdkit-log-filter.pod...

...ot;, (1, 0); > + "set_tls_certificates", (1, 0); > + (*"get_tls_certificates", (1, 0);*) If we ever do implement this (and any other commented out for various reasons), it won't be a 1.0 version... > + > + (* Added in 1.1 development series. *) > + "can_fast_zero", (1, 2); ..so maybe it's better to sink the commented future APIs to the bottom? -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org