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

[Anthony Liguori <anthony@codemonkey.ws>]

Daniel P. Berrange wrote:
> On Wed, Jan 14, 2009 at 04:46:17PM +0000, Jamie Lokier wrote:
>   
>> Daniel P. Berrange wrote:
>>     
>>> Thus I'd suggest we need an async notification of this event,
>>> and only enable this behaviour if the app controlling QEMU has
>>> explicitly enabled this notification / feature.
>>>       
>> I think the behaviour should always be enabled (unless explicitly
>> disabled, but I'm not sure why you'd want to do that).
>>
>> A corrupt VM with data loss sounds much worse than a stopped VM to me.
>>     
>
> You're not corrupting data in current code - you're just unable to finish
> new writes, because an IO failure is propagated back to the guest. If the
> guest is properly checking for & handling I/O failures, it should be pretty
> much OK once the host space problem is resolved - perhaps a reboot + journal
> recovery. 
>   

Not at all.  When the guest gets an IO error, it's going to try and mark 
the sector bad and move on.  If it does do a journal recover on reboot, 
you're even more screwed because writes will randomly fail.  Writes to 
pre-allocated storage will succeed but unallocated storage will fail.

The guest has no awareness into this error scenario so there's nothing 
that it can reasonably do to recover.

> Older QEMU certainly had catastrophic data loss on ENOSPC due to not sending
> any I/O errors back to the guest, so it thought its write had succeeded when
> in fact it had been thrown away. Current QEMU is more careful about error
> propagation now.
>   

But the error propagation in the event of ENOSPC is totally wrong.  Try 
it out and your guest will corrupt itself.  It's even more catastrophic 
with qcow2 but that shouldn't be surprising at this point.

Regards,

Anthony Liguori

> Daniel
>