search for: b3a43ccd

...hread_mutex_t lock = PTHREAD_MUTEX_INITIALIZER; > + > +/* The real size of the underlying plugin. */ > +static uint64_t size; > + We recently just fixed the truncate filter to NOT cache this globally (as doing so is too risky); instead, it needs to be cached per-connection. See commit b3a43ccd. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org

We don't know how long a plugin's .get_size() will take, but we also documented that it shouldn't change per connection and therefore can be cached. It's not hard to see that we have to consult the size per connection (see commit b3a43ccd for a test that purposefully exposes different sizes to separate clients), nor to search the code to see we already cache it at the protocol level, given that each .extents call refers to the current size: $ cat script case "$1" in get_size) sleep 1; echo 1m;; can_extents) ;;...

This filter caches the last result of the extents() call and offers a nice speed-up for clients that only support req_on=1 in combination with plugins like vddk, which has no overhead for returning information for multiple extents in one call, but that call is very time-consuming. Quick test showed that on a fast connection and a sparsely allocated 16G disk with a OS installed `qemu-img map` runs

It's easy to use the sh script to demonstrate that nbdkit is inefficiently calling into .get_size, .can_fua, and friends more than necessary. We've also commented on the list in the past that it would be nice to ensure that when filters call into next_ops, they are not violating constraints (as we've have to fix several bugs in the past where we did not have such checking to protect