similar to: [nbdkit PATCH 0/3] Test zero callback of python plugin

Begin the language binding followups to my new .zero callback, since Rich was indeed correct that we want them. I'm more familiar with python and perl (at least to the point that I was able to modify the appropriate example files and prove to myself that the bindings worked), so I've started with those. I'm less familiar with ruby and ocaml, so I've left those for tomorrow (it

The upstream protocol recently promoted NBD_CMD_WRITE_ZEROES from experimental to a documented extension. Exposing support for this allows plugin writers to create sparse files when driven by a client that knows how to use the extension; meanwhile, even if a plugin does not support this extension, the server benefits from less network traffic from the client. Eric Blake (5): protocol: Support

On 01/24/2017 05:38 AM, Richard W.M. Jones wrote: > On Mon, Jan 23, 2017 at 09:13:23PM -0600, Eric Blake wrote: >> Begin the language binding followups to my new .zero callback, since >> Rich was indeed correct that we want them. >> >> I'm more familiar with python and perl (at least to the point that >> I was able to modify the appropriate example files and

Fix some things I noticed while reviewing v1, and follow Rich's idea to add a new nbdkit_set_error() utility function with a binding for Python users to request a particular error (rather than being forced to live with whatever stale value is in errno after all the intermediate binding glue code). I could not easily find out how to register a C function callable from perl bindings, and have

On Tue, Apr 10, 2018 at 02:07:33PM +0000, Nir Soffer wrote: > This makes sense if the device is backed by a block device on oVirt side, > and the NBD support efficient zeroing. But in this case the device is backed > by an empty sparse file on NFS, and oVirt does not support yet efficient > zeroing, we just write zeros manually. > > I think should be handled on virt-v2v plugin

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.

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.

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

The existing test of language bindings was not covering any use of NBD_CMD_WRITE_ZEROES, making it harder to test changes to the plugin's zero callback. Recent Linux kernels are now smart enough to turn fallocate(2) with FALLOC_FL_ZERO_RANGE into a SCSI WRITE SAME request, which qemu in turn converts into an NBD_CMD_WRITE_ZEROES. Since libguestfs does not directly have an API for this, we

And fill out most of the missing bits of the API. Rich.

In libguestfs we have a few tests that require root privileges and they are skipped by default (normally you should not build or test as root), but you can do this to run them: sudo make check-root In nbdkit I wanted to check that the file plugin works with block devices (this is not tested), and the only way I can sensibly think to do this is using a loopback device and root. This commit

On 11/22/19 1:53 PM, Richard W.M. Jones wrote: > To avoid breaking existing plugins, Python plugins wishing to use > version 2 of the API must opt in by declaring: > > def api_version(): > return 2 > > (Plugins which do not do this are assumed to want API version 1). Could we also permit the python code to declare a global variable instead of a function? But a

Am 10.04.2018 um 15:03 hat Nir Soffer geschrieben: > On Tue, Apr 10, 2018 at 1:44 PM Richard W.M. Jones <rjones@redhat.com> > wrote: > > > We now have true zeroing support in oVirt imageio, thanks for that. > > > > However a problem is that ‘qemu-img convert’ issues zero requests for > > the whole disk before starting the transfer. It does this using 32 MB

As suggested by Nir, here: https://www.redhat.com/archives/libguestfs/2019-November/thread.html#00220

When using block device on RHEL 7.5, file plugin fails to zero with this error (copied from strace): [pid 39551] fallocate(8, FALLOC_FL_ZERO_RANGE, 1536, 64000) = -1 ENODEV (No such device) This is expected error according to the manual: ENODEV fd does not refer to a regular file or a directory. (If fd is a pipe or FIFO, a different error results.) Treat this error as EOPNOSUPP. Tested only

As mentioned in my reviews, I wonder if we should make our python callbacks look a bit more Pythonic by having kwargs added for each new flag that we want to expose. The idea was first floated here: https://www.redhat.com/archives/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

Tested via: term1$ qemu-nbd -k $PWD/sock -t -f raw -x foo junk --trace=nbd_\* term2$ ./nbdkit -f -v -e bar nbd socket=$PWD/sock export=foo term3$ qemu-io -t none -f raw nbd://localhost:10809/bar --trace=nbd_\* and checking the traces to see that 'w 0 1' vs. 'w -f 0 1' was able to influence whether the FUA flag showed up at the server in term1. Still to go: figure out how to

Similar to python and perl. But MUCH easier (especially considering that this is the first time I've every tried to run Ruby). I even had fun making set_error() polymorphic. Eric Blake (2): ruby: Expose nbdkit_set_error to ruby script ruby: Support zero callback plugins/ruby/example.rb | 11 ++++++++ plugins/ruby/nbdkit-ruby-plugin.pod | 54

This is the second version to support efficient zero for block devices on older kernels (e.g. RHEL 7.5), and file systems that do not support yet FALLOC_FS_ZERO_RANGE (e.g. NFS 4.2). Changes since v1: - Split to smaller patches - Skip linux only includes on other systems - Skip code using BLKZEROOUT if the macro is not defined - Try BLKZEROOUT only if the offset and count are aligned to device

On Fri, Jul 27, 2018 at 04:23:10PM -0500, Eric Blake wrote: > On 07/27/2018 04:03 PM, Nir Soffer wrote: > >When using block device on RHEL 7.5, file plugin fails to zero with this > >error (copied from strace): > > > >[pid 39551] fallocate(8, FALLOC_FL_ZERO_RANGE, 1536, 64000) = -1 ENODEV (No such device) > > > >This is expected error according to the manual: