Re: [Qemu-devel] [PATCH] report read/write errors to IDE guest driver as ECC errors

[Daniel P. Berrange]

On Tue, Aug 05, 2008 at 09:26:14PM -0500, Anthony Liguori wrote:
> Samuel Thibault wrote:
> >report read/write errors to IDE guest driver as ECC errors
> >so that the guest knows that e.g. writes on read-only backends have
> >failed.
> >
> >Signed-off-by: Samuel Thibault <address@hidden>
> >  
> 
> I'm glad you sent this patch as I think it's something we really need to 
> improve in QEMU.
> 
> A patch like this has appeared on the list a number of times, and each 
> time it meets with a fair bit of criticism.  The most  cited issue is 
> that indiscriminately passing IO errors to the guest is not really 
> correct.  If you're passing through a drive, then EIO errors are pretty 
> reasonable to pass through as an ECC error.  If you're dealing with a 
> file, generating an ECC error on ENOSPC is not really accurate.  The 
> guest cannot really do anything about that either and is likely to just 
> further corrupt itself.

If you have a journalling filesystem, the worst that'll happen in the
ENOSPC scenario is that you'll loose data from the open application files
that aren't flusshed to disk - no different to pulling the power plug.
The filesystem itself will not corrupt itself - it'll happily recover
the journal & carry on after rebootint.

> I think a patch like this is good in theory but it needs to do a better 
> job only handling the case where an error occurs that ECC really makes 
> sense.
> 
> For things like ENOSPC, there are better error handling strategies.  For 
> instance, vm_stop()'ing the guest and printing out an error message.  
> This would allow the admin to free up some space, and then resume the 
> guest.  Even if you just stubbed these things out with FIXMEs, it would 
> be better than pretending that these cases didn't exist :-)

Unless someone wants to implement the ENOSPC handling right now, I'd 
like to see this patch just committed as is, so we at least get
incremental benefit over current behaviour, which definitely *does*
corrupt guest filesystems by silently pretending the write succeeed.
Special ENOSPC handling can be added on top.

I agree that pausing the guest is probably best option in that scenario,
the interesting question being how to inform management tools/API that
the VM has just paused itself. In libvirt we handle pause/resume by doing
'stop'/'cont' in the QEMU monitor, and since we're triggering it ourselves
we can track the state change from running to paused. If the VM pauses
itself though we nee to figure out a way to detect this state change.
The monitor doesn't have any asynchronous notification capability as it
stands.

Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|