From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Npl4a-0003iX-P7 for qemu-devel@nongnu.org; Thu, 11 Mar 2010 11:17:20 -0500 Received: from [199.232.76.173] (port=55965 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Npl4a-0003iM-Cg for qemu-devel@nongnu.org; Thu, 11 Mar 2010 11:17:20 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1Npl4Z-0000DB-IT for qemu-devel@nongnu.org; Thu, 11 Mar 2010 11:17:20 -0500 Received: from mx1.redhat.com ([209.132.183.28]:65415) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Npl4Z-0000Cy-2G for qemu-devel@nongnu.org; Thu, 11 Mar 2010 11:17:19 -0500 Message-ID: <4B991760.1020706@redhat.com> Date: Thu, 11 Mar 2010 17:16:32 +0100 From: Kevin Wolf MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 0/3]: BLOCK_WATERMARK QMP event References: <1268175216-3600-1-git-send-email-lcapitulino@redhat.com> <4B96D4F1.80405@codemonkey.ws> <4B975B0A.1030502@redhat.com> <4B980D26.8070000@codemonkey.ws> <4B98AB17.8080506@redhat.com> <4B98FBE8.5050708@codemonkey.ws> In-Reply-To: <4B98FBE8.5050708@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: uril@redhat.com, qemu-devel@nongnu.org, Luiz Capitulino Am 11.03.2010 15:19, schrieb Anthony Liguori: > On 03/11/2010 02:34 AM, Kevin Wolf wrote: >> >> Well, if you're aware of the semantics of this value, it might be. It's >> not exactly intuitive, but this is currently hidden inside qemu. >> >> What the high watermark says (in this implementation) is the highest >> offset into the image file of an cluster that was allocated during this >> qemu run. If you restart qemu, it starts at 0 again. >> >> I think there once was a version that tried to calculate the absolute >> highest value when the image was opened, but it was reverted because it >> just took too long. For the same reason I think a low watermark is >> unrealistic, even if we get shrinking images some time. It's just not >> doable efficiently, at least not in an easy way. >> >> I'm not sure if this semantics makes it a good public interface. Other >> than that, I'm not overly concerned with doing it like you suggest. > > Making it an event certainly exposes it as part of the public interface > though, no? Not sure if we're talking about the same "it". If we generate an event when the absolute value goes over a given threshold we hide the somewhat non-intuitive part of the mechanism, which is the absolute number itself. >> But honestly, while I do understand your point, this feels like a hack >> to work around shortcomings of an interface. So what we need to decide >> is which criterion outweighs the other in practice. > > If I understand the use case correctly, what this really boils down to > is that you want to create a growable image on top of a non-growable > device. The management tool then deals with growth using this interface. > > I'm somewhat inclined to suggest that the proper way to support this is > to teach qemu how to grow the LVM volume like it would grow any normal file. Hm... Never thought about that. I'm somewhat inclined to suggest that you have a point there. :-) This probably means that we finally need to get the image formats (raw, qcow2, ...) and the protocols (file, host_cdrom, lvm, ...) properly separated. Which is a good thing because we should do it anyway. Kevin