Re: [Libguestfs] [PATCH nbdkit v4 2/2] cache: Implement cache-max-size and method of reclaiming space from the cache.

> /* Size of a block in the cache. A 4K block size means that we need > * 64 MB of memory to store the bitmaps for a 1 TB underlying image. > * It is also smaller than the usual hole size for sparse files, which Question - how on earth is this supposed to work when we run the cache with BLKSIZE 4096 - punching holes typically is a no-op unless you have a large enough block to actually warrant a hole in the file, and I don't know that 4k is big enough. Does the kernel coalesce fallocate() calls over consecutive regions of a file until it has enough to actually punch a hole? In which case, your test might happen to show that it "works" in that you end up punching some holes due to large blocks of consecutive less-frequently-used clusters after several combined fallocate() calls; but a different test that is truly random-access will be dirtying enough sub-hole regions that you can't reclaim anything? Or do you need the cache module to use a larger block size by default, or even add a parameter to control the block size?

Is this code thread-safe?

fallocate() fails with EINVAL if BLKSIZE is not a multiple of the filesystem block size, which gets back to my question of how this can even work on something that mandates 4k or even 64k access, if the cache block size is not configurable.