qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v2] xen_disk: support "direct-io-safe" backend o


From: Stefano Stabellini
Subject: Re: [Qemu-devel] [PATCH v2] xen_disk: support "direct-io-safe" backend option
Date: Fri, 28 Jun 2013 11:57:18 +0100
User-agent: Alpine 2.02 (DEB 1266 2009-07-14)

On Fri, 28 Jun 2013, Paolo Bonzini wrote:
> Il 27/06/2013 20:16, Stefano Stabellini ha scritto:
> > Support backend option "direct-io-safe".  This is documented as
> > follows in the Xen backend specification:
> > 
> >  * direct-io-safe
> >  *      Values:         0/1 (boolean)
> >  *      Default Value:  0
> >  *
> >  *      The underlying storage is not affected by the direct IO memory
> >  *      lifetime bug.  See:
> >  *        http://lists.xen.org/archives/html/xen-devel/2012-12/msg01154.html
> >  *
> >  *      Therefore this option gives the backend permission to use
> >  *      O_DIRECT, notwithstanding that bug.
> >  *
> >  *      That is, if this option is enabled, use of O_DIRECT is safe,
> >  *      in circumstances where we would normally have avoided it as a
> >  *      workaround for that bug.  This option is not relevant for all
> >  *      backends, and even not necessarily supported for those for
> >  *      which it is relevant.  A backend which knows that it is not
> >  *      affected by the bug can ignore this option.
> >  *
> >  *      This option doesn't require a backend to use O_DIRECT, so it
> >  *      should not be used to try to control the caching behaviour.
> > 
> > Also, BDRV_O_NATIVE_AIO is ignored if BDRV_O_NOCACHE, so clarify the
> > default flags passed to the qemu block layer.
> > 
> > The original proposal for a "cache" backend option has been dropped
> > because it was believed too wide, especially considering that at the
> > moment the backend doesn't have a way to tell the toolstack that it is
> > capable of supporting it.
> 
> Given how rusty my xenstore-fu is, I'll ask the obvious: the frontend
> cannot write to it, can it?

Nope, this option lives under the backend path, that is read-only for
the frontend



reply via email to

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