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

[Richard W.M. Jones]

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