Re: [Qemu-devel] [PATCH v4] Stop VM on ENOSPC error.

[Gleb Natapov <gleb@redhat.com>]

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.