From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LPgT9-0001mX-PZ for qemu-devel@nongnu.org; Wed, 21 Jan 2009 12:02:23 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LPgT8-0001lI-2Z for qemu-devel@nongnu.org; Wed, 21 Jan 2009 12:02:23 -0500 Received: from [199.232.76.173] (port=51306 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LPgT7-0001l5-Ti for qemu-devel@nongnu.org; Wed, 21 Jan 2009 12:02:21 -0500 Received: from mx2.redhat.com ([66.187.237.31]:59197) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LPgT7-0004Ea-9H for qemu-devel@nongnu.org; Wed, 21 Jan 2009 12:02:21 -0500 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n0LH2Jj5029561 for ; Wed, 21 Jan 2009 12:02:19 -0500 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n0LH2J1K028754 for ; Wed, 21 Jan 2009 12:02:19 -0500 Received: from dhcp-1-237.tlv.redhat.com (dhcp-1-237.tlv.redhat.com [10.35.1.237]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n0LH2J9k018845 for ; Wed, 21 Jan 2009 12:02:19 -0500 Date: Wed, 21 Jan 2009 19:00:30 +0200 From: Gleb Natapov Subject: Re: [Qemu-devel] [PATCH v4] Stop VM on ENOSPC error. Message-ID: <20090121170030.GA16094@redhat.com> 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> <20090120182344.GA12718@redhat.com> <18807.20276.763061.774652@mariner.uk.xensource.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <18807.20276.763061.774652@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 On Wed, Jan 21, 2009 at 04:37:08PM +0000, Ian Jackson wrote: > > Before? How should we know before specific format write if there is > > enough space? And block.c is called by different file formats too. So > > what do you suggest to do inside bdrv_write() function when write failed? > > I meant `before' in the calling stack sense rather than a temporal > sense. `Above' if you prefer. > > bdrv_[p]write would simply fail - as indeed they do in your patch. > > But ide.c doesn't call bdrv_pwrite; it calls bdrv_aio_write. > bdrv_aio_write would do what your ide.c code currently does. > ide.c calls bdrv_write. > > > 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. > > > > It may reenter block formats many times during one write from ide. > > Look at block-qcow2.c and calls to bdrv_pwrite() there. > > Yes. All of those calls would be allowed to fail with ENOSPC, just as > in your patch all of the block layer is untouched ane ENOSPC is > propagated upwards. > > I'm suggesting that instead of catching it in ide.c we should catch it > in bdrv_aio_write. bdrv_aio_write can request a VM stop and then > return to its caller. Well, actually, we'd have to insert a wrapper > around the BlockDriverCompletionFunc so that drv->bdrv_aio_write > doesn't return to the caller directly; instead, it would thread > through a new function (`bdrv_aio_write_cb' perhaps). > > bdrv_aio_write_cb would check for errors which would stop the VM, and > in those cases it would request a VM stop and put the request on a > queue (maintained in block.c) for retry on restart. > And synchronous calls will behave differently. I am all for doing it in one place, but I am against doing it just for part of API calls. So do you have better solution for sync calls except don't use them? And BTW block.c is compiled also for qemu-{img|mbd} no vmstop there. -- Gleb.