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

Richard W.M. Jones rjones at redhat.com
Thu Jan 3 18:56:43 UTC 2019


On Thu, Jan 03, 2019 at 12:09:46PM -0600, Eric Blake wrote:
> >  /* 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?

I'm going to guess that it doesn't work if the filesystem block size
is > 4K.  My understanding from fallocate(2) is that each cache block,
being smaller than any filesystem block, will be zeroed out rather
than hole-punched.

The block size on my system is 4K which would be why the test works.

I'll have to give this some more thought.  Maybe we can set BLKSIZE to
the max of (4K, filesystem block size) ...

> Is this code thread-safe?

As you say it needs to be holding the blk lock (which it does).  I
added a comment.

> 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.

I think actually it zeroes rather than failing, but yes - see above.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html




More information about the Libguestfs mailing list