From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LPLCU-0007Qj-DM for qemu-devel@nongnu.org; Tue, 20 Jan 2009 13:19:46 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LPLCT-0007PQ-JP for qemu-devel@nongnu.org; Tue, 20 Jan 2009 13:19:45 -0500 Received: from [199.232.76.173] (port=55866 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LPLCT-0007PF-Ev for qemu-devel@nongnu.org; Tue, 20 Jan 2009 13:19:45 -0500 Received: from mail2.shareable.org ([80.68.89.115]:44676) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LPLCT-0000zs-4S for qemu-devel@nongnu.org; Tue, 20 Jan 2009 13:19:45 -0500 Received: from jamie by mail2.shareable.org with local (Exim 4.63) (envelope-from ) id 1LPLCR-0007LL-I7 for qemu-devel@nongnu.org; Tue, 20 Jan 2009 18:19:43 +0000 Date: Tue, 20 Jan 2009 18:19:43 +0000 From: Jamie Lokier Subject: Re: [Qemu-devel] [PATCH v4] Stop VM on ENOSPC error. Message-ID: <20090120181943.GC27464@shareable.org> References: <20090120105610.GB27675@redhat.com> <18805.55601.339210.692083@mariner.uk.xensource.com> <20090120141651.GF27675@redhat.com> <18805.58968.356765.658443@mariner.uk.xensource.com> <20090120153159.GA8319@redhat.com> <18806.198.448290.48055@mariner.uk.xensource.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <18806.198.448290.48055@mariner.uk.xensource.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Ian Jackson wrote: > Gleb Natapov writes ("Re: [Qemu-devel] [PATCH v4] Stop VM on ENOSPC error."): > > I would like to abolish the blocking calls from all file formats, but in > > reality it is almost impossible. Qcow2 metadata updates is a big mess to > > do asynchronously. The best thing we can do is to move it to another thread. > > Err, I wasn't suggesting it should be done in each format in that way. > It could be done once in block.c, before the specific format write > method is called. > > So the formats would still write synchronously, and would pass errors > up to their parent formats, until it reenters the generic block code > where the retry would take place. At that point the call from the > device emulation would necessariy be asynchronous. Most of the block I/O is moving to threads anyway - if only to "emulate" AIO. If raw block I/O is going to use helper threads which do blocking I/O, it may be just as fast, and much simpler, to put the QCOW2 format block writes (including metadata) into those helper threads, instead of (avoiding) rewriting QCOW2 to do everything with AIO calls. -- Jamie