Am 30.10.2014 um 15:27 hat Eric Blake geschrieben:
> On 10/30/2014 06:26 AM, Kevin Wolf wrote:
> >
> > The other differences of this patch to the old one are that it doesn't
> > silently write something different than the guest requested by zeroing
> > out some bytes (it fails the request instead) and that it doesn't
> > maintain a list of signatures in the raw driver (it calls the usual
> > probe function instead).
> >
> > Signed-off-by: Kevin Wolf <kw...@redhat.com>
> > ---
> > block.c | 5 +++--
>
> > +
> > + drv = bdrv_probe_all(buf, 512, NULL);
> > + if (drv != bs->drv) {
> > + ret = -EPERM;
> > + goto fail;
> > + }
>
> So, what happens when this returns -EPERM? If the guest is configured
> to halt on write errors, does this halt the guest and send an event to
> management? How does it compare to the case of halting on ENOSPACE? Is
> this particular failure mode something that the host should be able to
> easily distinguish from other failure modes?This -EPERM is returned the same way as error that come directly from the kernel, so the usual werror/rerror rules apply. It can easily be distinguished from ENOSPC (nospace=false in the QMP event, io-status=failed in BlockInfo for query-block), but it looks the same as a regular I/O error. > But I definitely like that you only do this failure on probed images, > and that a user that requests an explicit raw format will never trip up. Right, a management tool should always be passing the format explicitly and shouldn't need to deal with this error case at all. Kevin
pgpjNbC4kmbU3.pgp
Description: PGP signature
