On 04/19/2018 09:54 AM, Richard W.M. Jones wrote: > I'm a bit unclear on what exactly this does. Is it like copy-on-read, > or readahead/prefetch? As documented by Vladimir, I'd say it is mostly a readahead/prefetch; but that when set up properly (where the server is already doing copy-on-read from a remote location), the client can use prefetch to force the server to copy-on-read the information from remote to local without wasting the bandwidth of telling the client what was fetched. But it could be more, if we also document some NBD_CMD_FLAG_* flags for mapping it more closely to posix_fadvise(). > > Not for or against this proposal, but I'd like to add that nbdkit > offers a copy-on-read-like facility already, but in a slightly > different way that doesn't have any impact on the NBD protocol. > One filter we already provide is called "cache" described as: > > "nbdkit-cache-filter is a filter that adds caching on top of a > plugin. This is useful if a plugin is slow or expensive to use, > because nbdkit will try to minimize requests to the plugin by > caching previous requests." > [https://github.com/libguestfs/nbdkit/blob/master/filters/cache/nbdkit-cache-filter.pod] > > Note this all happens internal to the NBD server so the client will > not see any difference (except perhaps enhanced performance). That particular filter currently only does a copy-on-read of portions that it also sends to the client; whereas this command would let the client do the copy-on-read action without also suffering from the network bandwidth of the client having to consume the data read from that portion of the file. Or, if (when?) nbdkit learns support for NBD_CMD_BLOCK_STATUS, this could also be a way to learn which portions of the file have been cached (whether directly due to normal reads/writes, or indirectly due to NBD_CMD_CACHE). -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature