From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NrErK-0004fC-Nq for qemu-devel@nongnu.org; Mon, 15 Mar 2010 14:17:46 -0400 Received: from [199.232.76.173] (port=51781 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NrErJ-0004eA-QT for qemu-devel@nongnu.org; Mon, 15 Mar 2010 14:17:45 -0400 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1NrErJ-0001WJ-2O for qemu-devel@nongnu.org; Mon, 15 Mar 2010 14:17:45 -0400 Received: from mail-pz0-f194.google.com ([209.85.222.194]:46897) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NrErI-0001WD-Mv for qemu-devel@nongnu.org; Mon, 15 Mar 2010 14:17:44 -0400 Received: by pzk32 with SMTP id 32so2094275pzk.4 for ; Mon, 15 Mar 2010 11:17:43 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <4B9E7496.6060102@redhat.com> References: <1268672915-12233-1-git-send-email-kwolf@redhat.com> <4B9E7496.6060102@redhat.com> Date: Mon, 15 Mar 2010 20:17:43 +0200 Message-ID: Subject: Re: [Qemu-devel] [RFC][PATCH 0/7] blkdebug From: Blue Swirl Content-Type: text/plain; charset=UTF-8 List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: qemu-devel@nongnu.org On 3/15/10, Kevin Wolf wrote: > Am 15.03.2010 18:40, schrieb Blue Swirl: > > > On 3/15/10, Kevin Wolf wrote: > >> This patch series introduces a new block driver which acts as a protocol and > >> whose purpose it is to fail requests. To be more precise, I want it to fail in > >> configurable places, so that qemu-iotests can be extended with tests for the > >> error paths (for example for the case when something with metadata writes goes > >> wrong deep in qcow2). > > > > Nice. Do you think this could be extended (later) to inject errors > > also to guest from QEMU? > > > Not sure what you mean by "from QEMU"? To allow injecting errors from > the monitor instead of based on rules? Sounds certainly doable. I was thinking rule file, but monitor would be more flexible. Even better: allow switching rule files from monitor :-). > Or do you just mean to make it work in qemu as opposed to qemu-io? This > really doesn't make a difference to the block layer. If it works in one, > it works in the other one, too. > > > > Then it would be nice to be able to inject > > errors when reading/writing to a specific guest block range and for > > other formats (raw etc.) too. > > > Should work with all formats, it's implemented as a protocol (but it's > untested with everything but qcow2). So you basically stick it between > the format driver and the image file. The only thing that could be > needed for other formats is some additional events. > > For the block range thing, this would need to implement some more > conditions instead of just checking the state, but in general this is > exactly the kind of things that I'd like to see supported eventually. > > So I completely agree that this is the right direction for future > improvements, however I can't tell yet if (or when) I'll get to > implement it myself. My focus is really the qcow2 error paths for now. Ok, it's enough to know at this stage that the architecture is flexible for this.