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

[Ian Jackson]

Gleb Natapov writes ("Re: [Qemu-devel] [PATCH v4] Stop VM on ENOSPC error."):
> On Tue, Jan 20, 2009 at 04:50:14PM +0000, 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.
> 
> 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.

> > 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.

Ian.