qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 2/3] qcow2: add option to clean unused cache ent


From: Kevin Wolf
Subject: Re: [Qemu-devel] [PATCH 2/3] qcow2: add option to clean unused cache entries after some time
Date: Fri, 29 May 2015 10:32:42 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

Am 28.05.2015 um 21:41 hat Eric Blake geschrieben:
> On 05/28/2015 09:23 AM, Max Reitz wrote:
> 
> >>>> Can we mark the parameter optional, and only provide it when it is
> >>>> non-zero?  That way, qemu-img (which cannot set an interval) will not
> >>>> report it, and the only time it will appear is if it was set as part
> >>>> of opening the block device under qemu.
> >>> That sounds good.
> >> But what do we do with the other parameters (refcount-cache-size,
> >> l2-cache-size)? We cannot have the same solution there because they
> >> don't belong to the image file either, and they're never going go be
> >> zero.
> > 
> > Pssht, don't mention it, or Eric will notice. :-)
> > 
> > Well, one solution would be to remember whether they have been set
> > explicitly or not. But that gets ugly really quickly. Maybe Kevin's
> > series helps there, but I don't know.
> > 
> > Of course, the simplest solution is to worry about cache-clean-interval
> > for now and worry about the cache sizes later… But that basically means
> > "We'll never worry about them unless someone complains", so…
> 
> Hmm, now that we have three pieces of data, I'm starting to lean more
> towards ImageInfoSpecific being the wrong place for this after all; it
> would still be nice to advertise all three, but where?  Is
> BlockdevCacheInfo more appropriate (as a sub-struct of BlockDeviceInfo)?

BlockDeviceInfo contains runtime information, so that looks like the
right place indeed. As these options aren't present for all devices, I
don't think we should extend BlockdevCacheInfo, but rather introduce a
BlockDeviceInfoSpecific that works like ImageInfoSpecific, just for
runtime information.

I agree with Berto that that's out of scope for this series, though.

Kevin

Attachment: pgpBHUTSKjwmF.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]