From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MXnFL-000453-Jx for qemu-devel@nongnu.org; Sun, 02 Aug 2009 22:25:55 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MXnFG-0003yi-Er for qemu-devel@nongnu.org; Sun, 02 Aug 2009 22:25:54 -0400 Received: from [199.232.76.173] (port=59305 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MXnFG-0003yV-92 for qemu-devel@nongnu.org; Sun, 02 Aug 2009 22:25:50 -0400 Received: from qw-out-1920.google.com ([74.125.92.145]:39216) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MXnFF-00064l-VU for qemu-devel@nongnu.org; Sun, 02 Aug 2009 22:25:50 -0400 Received: by qw-out-1920.google.com with SMTP id 5so1457994qwc.4 for ; Sun, 02 Aug 2009 19:25:49 -0700 (PDT) Message-ID: <4A764AAA.1030509@codemonkey.ws> Date: Sun, 02 Aug 2009 21:25:46 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] RFC: Add new block driver for the VDI format References: <4A4E5AFC.4020206@mail.berlios.de> <4A51FE07.2040307@codemonkey.ws> <4A75A242.9020005@redhat.com> In-Reply-To: <4A75A242.9020005@redhat.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Kevin Wolf , QEMU Developers , Christoph Hellwig Avi Kivity wrote: > On 07/06/2009 04:37 PM, Anthony Liguori wrote: >> >> I'd really like to get rid of synchronous IO functions in the block >> layer. One way to do this is to insist that all new block drivers >> only implement the AIO functions. >> >> I think we should make this decree but I'd like to know if other >> people think this is unreasonable first. One potential model of >> block drivers would involve synchronous IO and threads. I'm not a >> big fan of that model and I don't think it's an easy conversion from >> today's synchronous IO drivers to that model because the locking and >> re-entrance needs careful consideration. >> > > I agree that sync+threads is not easy, but well performing async is > much, much harder. Consider that qcow2 still has synchronous > operations, and that eliminating the RMW when writing a partial > cluster concurrently (a very common operation with 64K clusters) is > very hard to do ayncly and much easier syncly. Supporting parallel RMW operations is certainly difficult, but you're confusing parallel RMW ops with asynchronous RMW ops. You just have to queue requests and handle them in order. It's only mildly more difficult to deal with asynchronous I/O and it avoids all the nastiness associated with threads and locking. Fundamentally, threads don't help the RMW problem because you probably would just hold a look for the entire RMW operation so you're effectively queuing any RMW op. > Given in addition the large numbers of format drivers, I think we > should prefer sync+threads over trying to convert all format drivers > to full async. It's just shifting the problem from one place to another. Instead of figuring out the state machine, you have to figure out how to do the locking. The danger of the later is that it gives you the illusion that it's an easy problem and is therefore prone to error. Regards, Anthony Liguori