From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58105) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yxzez-0003BX-IC for qemu-devel@nongnu.org; Thu, 28 May 2015 11:23:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Yxzey-00079w-JH for qemu-devel@nongnu.org; Thu, 28 May 2015 11:23:53 -0400 Message-ID: <556732FC.4050803@redhat.com> Date: Thu, 28 May 2015 17:23:40 +0200 From: Max Reitz MIME-Version: 1.0 References: <8007efe81120cd72f7c4145b8bbc3f4bc558e62d.1432719752.git.berto@igalia.com> <55672CA2.10105@redhat.com> <556730A1.40705@redhat.com> <556730C4.60903@redhat.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 2/3] qcow2: add option to clean unused cache entries after some time List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alberto Garcia , Eric Blake , qemu-devel@nongnu.org Cc: Kevin Wolf , qemu-block@nongnu.org, Stefan Hajnoczi On 28.05.2015 17:19, Alberto Garcia wrote: > On Thu 28 May 2015 05:14:12 PM CEST, Max Reitz wrote: >>>>> 'compat': 'str', >>>>> '*lazy-refcounts': 'bool', >>>>> '*corrupt': 'bool', >>>>> - 'refcount-bits': 'int' >>>>> + 'refcount-bits': 'int', >>>>> + 'cache-clean-interval': 'int' >>>>> } } >>>> I'm not too happy about making this part of ImageInfoSpecificQCow2. >>>> Two reasons for this: First, it's eventually part of ImageInfo, >>>> which is defined as "Information about a QEMU image file", but this >>>> option cannot be set in the image file itself but is only a run-time >>>> option. >>>> >>> 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=20 explicitly or not. But that gets ugly really quickly. Maybe Kevin's=20 series helps there, but I don't know. Of course, the simplest solution is to worry about cache-clean-interval=20 for now and worry about the cache sizes later=85 But that basically means= =20 "We'll never worry about them unless someone complains", so=85 Max