On Thu, Dec 09, 2021 at 11:55:49AM +0100, Laszlo Ersek wrote:
On 12/08/21 16:21, Richard W.M. Jones wrote:
On Wed, Dec 08, 2021 at 01:20:49PM +0100, Laszlo Ersek wrote:
Add the "Nbdkit.get_disk_allocated" helper function, which calculates the number of allocated bytes in an output disk image, through a corresponding NBD server connection.
Original "NBD.block_status" summation example code by Rich Jones (thanks!), chunking, metadata context simplification, and virt-v2v integration by myself. Chunking added because "NBD.block_status" is not 64-bit clean just yet (Eric Blake is working on it).
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2027598 Signed-off-by: Laszlo Ersek <lersek@redhat.com> --- lib/nbdkit.mli | 8 ++++++ lib/nbdkit.ml | 30 ++++++++++++++++++++ 2 files changed, 38 insertions(+)
diff --git a/lib/nbdkit.mli b/lib/nbdkit.mli index 825755e61dbe..03107dab109d 100644 --- a/lib/nbdkit.mli +++ b/lib/nbdkit.mli @@ -117,3 +117,11 @@ val with_connect_unix : socket:string -> in [meta_contexts] requested (each of which is not necessarily supported by the server though). The connection is torn down either on normal return or if the function [f] throws an exception. *) + +val get_disk_allocated : dir:string -> disknr:int -> int64 option +(** Callable only in the finalization step. [get_disk_allocated dir disknr] + examines output disk [disknr] through the corresponding NBD server socket + that resides in [dir]. Returns the number of bytes allocated in the disk + image, according to the "base:allocation" metadata context. If the context + is not supported by the NBD server behind the socket, the function returns + None. *)
This really is the right function, wrong module.
Since it only applies to output modules, the logical place is in output/output.ml, where there are already a bunch of random helper functions.
That's precisely where I put it first (given that we have "get_disks" there too!). However, I proved simply unable to *call* the function, from "lib/create_ovf.ml", in the next patch!
Oh indeed - I didn't spot it was called from lib/
I tried "Output.get_disk_allocated", and I got a weird compilation failure, even though the function was properly declared in "output.mli".
Yes you cannot just call randomly between modules (as in, say, C) because OCaml enforces a strict ordering of top level values when the program is loaded. If you could call randomly then you might call a function before any top level values it needs have been initialized, and that would cause undefined behaviour. In this case just put it in lib/utils.ml and it'll be fine.
At that point, I couldn't decide if I was missing something about the tricky "first class modules" thing, or if it was really a layering violation to call an Output function from a *lower level* utility function (such as "create_ovf" in "lib/create_ovf.ml").
Yes it's a layering thing. [...] Other suggestions look complicated. Best to put it in lib/utils.ml We can always move things around later if we discover a cleaner way. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org