On 01/21/2018 04:08 PM, Richard W.M. Jones wrote:
Here's the patch (on top of the preceeding one) which uses a
bitmap
instead of SEEK_DATA.
Yep, I think we'll need this. But perhaps you can have both styles, and
provide a config knob for users to tune which of the two styles they want?
+++ b/filters/cow/cow.c
@@ -38,20 +38,22 @@
* takes up no space.
*
* We confine all pread/pwrite operations to the filesystem block
- * size. The blk_read and blk_write functions below always happen on
- * whole filesystem block boundaries. A smaller-than-block-size
- * pwrite will turn into a read-modify-write of a whole block. We
- * also assume that the plugin returns the same immutable data for
- * each pread call we make, and optimize on this basis.
+ * size. The blk_* functions below only work on whole filesystem
+ * block boundaries. A smaller-than-block-size pwrite will turn into
+ * a read-modify-write of a whole block. We also assume that the
+ * plugin returns the same immutable data for each pread call we make,
+ * and optimize on this basis.
*
- * When reading a block we first check the temporary file to see if
- * that file block is allocated or a hole. If allocated, we return it
- * from the temporary file. If a hole, we issue a pread to the
- * underlying plugin.
+ * A block bitmap is maintained in memory recording if each block in
+ * the temporary file is "allocated" (1) or "hole" (0).
+ *
+ * When reading a block we first check the bitmap to see if that file
+ * block is allocated or a hole. If allocated, we return it from the
+ * temporary file. If a hole, we issue a pread to the underlying
+ * plugin.
Do we also want a knob that says whether to cache things in the
temporary file (copy-on-read)? That way, a user can choose whether to
cache things locally rather than always reading from the underlying
plugin, even for blocks that do not get written.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization:
qemu.org |
libvirt.org