Re: [Qemu-devel] Xen patches - status summary

[Ian Jackson]

Anthony Liguori writes ("Re: [Qemu-devel] Xen patches - status summary"):
> Ian Jackson wrote
> > I summarised the discussion in my message `[REPOST] [PATCH 0/2]'.
> > There has been no recent response.  For the reasons I explain, I think
> > this patch should be applied now without waiting for any
> > ENOSPC-auto-pause feature.
> 
> For the vast majority of users, ENOSPC is the only realistic error that 
> will occur.  I don't think a patch that doesn't handle ENOSPC in a sane 
> way is really that useful.

I find it surprising that you're taking this line.

Are you really saying that it is better for the guest's data to be
silently corrupted, by pretending that the write happened when in fact
it didn't, than it is to give the guest an error indication ?  The
current code in qemu silently discards many error indications and
allows the guest to continue in blissful ignorance.

If that's not what you're saying then surely my patch is an
improvement ?  The fact that it doesn't make the situation as good as
you think it could be doesn't mean that it isn't correct or useful.

Even if you think my patch is pointless it makes no harmful change to
the functionality and lays the groundwork for a more sophisticated
treatment: it adds the missing return values to bdrv_ functions, and
the capability to return non-ENOSPC errors to guests.

It may be the case that for many of qemu's users errors are largely a
result of COW ENOSPC, and that this differs from the situation with
Xen where more of the users are doing RAID or NAS with more
sophisticated guests which can be expected to handle errors properly.
That might explain a difference in emphasis and lead to different
conclusions about whether (for example) the default should be to pause
a VM when ENOSPC is detected.

But _even if_ you think the right default behaviour is actually to
pause a VM when ENOSPC is detected, there are certainly users and
contexts who will want a different configuration (in the Xen case it's
very tricky for qemu to unilaterally pause the VM).

Ian.