From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O6kXD-0000cc-JH for qemu-devel@nongnu.org; Tue, 27 Apr 2010 09:09:07 -0400 Received: from [140.186.70.92] (port=40218 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O6kXC-0000b6-2j for qemu-devel@nongnu.org; Tue, 27 Apr 2010 09:09:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O6kX9-0000GB-Q1 for qemu-devel@nongnu.org; Tue, 27 Apr 2010 09:09:05 -0400 Received: from mx1.redhat.com ([209.132.183.28]:63763) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O6kX4-0000FR-RT for qemu-devel@nongnu.org; Tue, 27 Apr 2010 09:08:59 -0400 Message-ID: <4BD6E1E7.2080802@redhat.com> Date: Tue, 27 Apr 2010 16:08:55 +0300 From: Avi Kivity MIME-Version: 1.0 References: <20100426172634.GC15278@x200.localdomain> <4BD5D28C.7080700@codemonkey.ws> <20100426221258.GH15278@x200.localdomain> <4BD61584.9080208@codemonkey.ws> <4BD69D03.2050502@redhat.com> <4BD6E0AE.8020307@codemonkey.ws> In-Reply-To: <4BD6E0AE.8020307@codemonkey.ws> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: KVM call agenda for Apr 27 List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Chris Wright , qemu-devel@nongnu.org, kvm@vger.kernel.org On 04/27/2010 04:03 PM, Anthony Liguori wrote: > On 04/27/2010 03:14 AM, Avi Kivity wrote: >> On 04/27/2010 01:36 AM, Anthony Liguori wrote: >>> >>> A few comments: >>> >>> 1) The problem was not block watermark itself but generating a >>> notification on the watermark threshold. It's a heuristic and >>> should be implemented based on polling block stats. >> >> Polling for an event that never happens is bad engineering. What >> frequency do you poll? you're forcing the user to make a lose-lose >> tradeoff. >> >>> Otherwise, we'll be adding tons of events to qemu that we'll >>> struggle to maintain. >> >> That's not a valid reason to reject a user requirement. We may argue >> the requirement is bogus, or that the suggested implementation is >> wrong and point in a different direction, but saying that we may have >> to add more code in the future due to other requirements is ... well >> I can't find a word for it. > > Polling is the best solution because it offers the most flexibility. > Baking the heuristic into qemu just removes flexibility for all > consumers. Can you explain? The ability to poll is not removed. Nor is any heuristics performed by qemu; it just sends a notification when a write exceeds a user-defined threshold. The distance from the threshold to the top-of-file is not known to qemu. > >>> >>> 2) A block plugin doesn't solve the problem if it's just at the >>> BlockDriverState level because it can't interact with qcow2. >> >> Why not? We have a layered model. guest -> qcow2 -> plugin (sends >> event) -> raw-posix. Just need to insert the plugin at the >> appropriate layer. > > All of the qcow2 information is static to the qcow2 driver and I don't > think changing that for plugins is a good idea. There is no information that the plugin needs to access: if (write_offset > watermark && watermark_enabled) { send_notification(); watermark_enabled = false; } bdrv_write(backing_blockstate, ..., write_offset, ...); Note write_offset if not the guest's offset, but the offset into the backing file. It will trigger on guest writes and qcow2 metadata writes alike. > >>> >>> 3) For general block plugins, it's probably better to tackle >>> userspace block devices. We have CUSE and FUSE already, a BUSE is a >>> logical conclusion. >> >> We also have an nbd client. >> >> Here's another option: an nbd-like protocol that remotes all >> BlockDriver operations except read and write over a unix domain >> socket. The open operation returns an fd (SCM_RIGHTS strikes again) >> that is used for read and write. This can be used to implement >> snapshots over LVM, for example. > > How does it address the watermark problem? It doesn't. Mea confusa. -- error compiling committee.c: too many arguments to function