[Libguestfs] [PATCH nbdkit v5 FINAL 05/19] cache: Add a comment about possible future handling of extents.

This filter should be correct without intercepting the .extents or .can_extents callbacks, so we don't need to implement this now. Thanks: Eric Blake. --- filters/cache/blk.c | 15 +++++++++++---- 1 file changed, 11 insertions(+), 4 deletions(-) diff --git a/filters/cache/blk.c b/filters/cache/blk.c index d708a54..56c6ab9 100644 --- a/filters/cache/blk.c +++ b/filters/cache/blk.c @@ -69,10 +69,17 @@ static int fd = -1; * 10 = <unused> * 11 = block cached and dirty * - * Idea for future enhancement: Use 10 (currently unused) to store - * blocks which are known to be zero and are not allocated in the - * cache layer. You can set this when clients call cache_zero and - * defer calling plugin->zero until flush. + * Future enhancement: + * + * We need to cache information about holes, ie. blocks which read as + * zeroes but are not explicitly stored in the cache. This + * information could be set when clients call cache_zero (and defer + * calling plugin->zero until flush). The information could also + * interact with extents, so when plugin->extents returns information + * that a hole exists we can record this information in the cache and + * not have to query the plugin a second time (especially useful for + * VDDK where querying extents is slow, and for qemu which [in 2019] + * repeatedly requests the same information with REQ_ONE set). */ static struct bitmap bm; -- 2.20.1