From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48660) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YyFim-0006HH-7W for qemu-devel@nongnu.org; Fri, 29 May 2015 04:32:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YyFil-00083d-Dv for qemu-devel@nongnu.org; Fri, 29 May 2015 04:32:52 -0400 Date: Fri, 29 May 2015 10:32:42 +0200 From: Kevin Wolf Message-ID: <20150529083242.GA3804@noname.redhat.com> References: <8007efe81120cd72f7c4145b8bbc3f4bc558e62d.1432719752.git.berto@igalia.com> <55672CA2.10105@redhat.com> <556730A1.40705@redhat.com> <556730C4.60903@redhat.com> <556732FC.4050803@redhat.com> <55676F69.1000804@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FL5UXtIhxfXey3p5" Content-Disposition: inline In-Reply-To: <55676F69.1000804@redhat.com> 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: Eric Blake Cc: qemu-block@nongnu.org, Alberto Garcia , qemu-devel@nongnu.org, Stefan Hajnoczi , Max Reitz --FL5UXtIhxfXey3p5 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Am 28.05.2015 um 21:41 hat Eric Blake geschrieben: > On 05/28/2015 09:23 AM, Max Reitz wrote: >=20 > >>>> 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. > >=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 >=20 > 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 --FL5UXtIhxfXey3p5 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJVaCQqAAoJEH8JsnLIjy/WPdsP/3fc7DF4R7qf/TgSJ+TnY+in JRuJsj8O5GS0tUIzJQxnxpC7LxhCDHrvrVSsYpx/OF8VZt00GI8wTnvV/jyT7pPF K9l4+eDfSBvdVq//owfO1Gp3BoKSy2L4effRtss7Z688GYH1yXTzwg7WVoqH3uxV hNxIT0qnS6c/Ia1VF65ffJhMrTQ4o7roETJIts5kBYDXvPcajYEOmHteVmIHR7aw nAtVcwtFyRowkPKbsHs9Lj86+THtLpSXywRDdRBJssZrfwVwsW3FZJg9MvScEENm iuhB6vLAdNmq3VSct3UOo9iDoLZ1z0Emg0ALFflJB5n2UvkxaiICG6mMzXDEymtk cUgfOQq6j4Jp6a3TE9kXrAFfv+XM6ijFuxjj0StiIebXo1Hxnc8qTjrNZuEjJYai j19H3McSfykoq9TJrU3Kltky2PvZ9edEChiphh74CFBgW/wSDSdzT1c3xkVkZQmS mLyo4mTAPBJjDxW6l6JB17gk/d/J0cDzBYvq27tLJaDd4KFTQOENbIeEDYKTDz5T MSEF0L1yZEQrV3sNNRiW41t5hWrOYPFhlkLnUxuEdjhkrJqhkuNWQZI1UyOb8g5b Vo7Gt2OHdP8RsHtL7Wn4VzWvyCsVkFxapwTEeA+7EBzXOpUyWMgBcQoCl87135Az SnUF/B8wNBN49xbZ83zE =mXV/ -----END PGP SIGNATURE----- --FL5UXtIhxfXey3p5--