[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH] Stop VM on ENOSPC error
Date: Wed, 14 Jan 2009 12:29:49 -0600
User-agent: Thunderbird (X11/20090105)

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

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.


Anthony Liguori


reply via email to

[Prev in Thread] Current Thread [Next in Thread]