From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53154) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yy3gZ-0007XI-AT for qemu-devel@nongnu.org; Thu, 28 May 2015 15:41:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Yy3gV-0007q7-4G for qemu-devel@nongnu.org; Thu, 28 May 2015 15:41:47 -0400 Message-ID: <55676F69.1000804@redhat.com> Date: Thu, 28 May 2015 13:41:29 -0600 From: Eric Blake MIME-Version: 1.0 References: <8007efe81120cd72f7c4145b8bbc3f4bc558e62d.1432719752.git.berto@igalia.com> <55672CA2.10105@redhat.com> <556730A1.40705@redhat.com> <556730C4.60903@redhat.com> <556732FC.4050803@redhat.com> In-Reply-To: <556732FC.4050803@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="9UARq85bRK7iU5dm0qBurFkGojF6V1f46" 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: Max Reitz , Alberto Garcia , qemu-devel@nongnu.org Cc: Kevin Wolf , qemu-block@nongnu.org, Stefan Hajnoczi This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --9UARq85bRK7iU5dm0qBurFkGojF6V1f46 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 no= t >>>> 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. >=20 > Pssht, don't mention it, or Eric will notice. :-) >=20 > 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. >=20 > Of course, the simplest solution is to worry about cache-clean-interval= > for now and worry about the cache sizes later=E2=80=A6 But that basical= ly means > "We'll never worry about them unless someone complains", so=E2=80=A6 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)? --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --9UARq85bRK7iU5dm0qBurFkGojF6V1f46 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJVZ29pAAoJEKeha0olJ0NqvpMH/iqPhGmRRIkEhmR2vJE1AKj4 Vn9HWdCLDqqnTfJ4zRvPzIUVZMd+bGp+cWa44hfg9qZAOvP+wLSLpHKdKl/adYeJ l6LZmbO4STGXf3AV3LLIBxWWmAwjmbH4Q00BYH05lxVaHHqQMi1fjb0ezOmJPJSL ER1YVZ4orcjmLS53a9aln3JpZThyYrvDw4GhZwjSy6bFcoJDFwmKxHG+6EX5oe9e MRvGsctoO1HPm/MxrU7sZiAicHGQlLbvD+YtqR6WeAcufVdymJCEJHIZFm9D6LQI hXEDsxzrAD5PfSrTSJmP1M6NxnSToFrxlNmzX0A0KB3+qRh8GGwQnL9ZVp/5Pk4= =lNGt -----END PGP SIGNATURE----- --9UARq85bRK7iU5dm0qBurFkGojF6V1f46--