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

[Jamie Lokier <jamie@shareable.org>]

Daniel P. Berrange wrote:
> > Or even to stop. What guest can do with other errors anyway?
> 
> The idea is that if the guest at least sees the I/O error, then it won't
> continue writing as if everything were OK. It may not be able to continue
> normal operation, but it can at least mark the FS read-only and avoid
> ongoing damage. So you have a reasonable liklihood of shutting down the
> guest, fixing the ENOSPC problem ont he host, and starting the guests
> again & them recovering their journal.  'ignore' is guarenteed dataloss,
> 'report' gives you a good fighting chance. 'stop'/'enospc' are best, if
> the management app is able to detect that the VM is being paused & thus
> report it to the user

Even Linux guests don't respond to an I/O error quite as above.  In
Linux, the I/O queue (elevator) may have additional pending write
commands which are executed despite an earlier "journal" write
failing.  This can result in an inconsistent filesystem if one write
fails and later ones succeed.  It's equivalent to losing power and
barriers not being honoured.

If QEMU were to have a "sticky" error flag which turns all writes into
I/O errors after a failed one, even if the host ENOSPC is transient,
that would be better for guest data consistency.  (Not perfect for
transactions spanning multiple disks (etc.), but good for a single
journalled filesystem).

-- Jamie