Re: [Xen-devel] [PATCH] libxl: introduce an option for disabling the non-O_DIRECT workaround [and 1 more messages]

[Felipe Franciosi <felipe.franciosi@xxxxxxxxxx>]

I would personally prefer to call the flag something else. But if this would 
delay checking in the patch, then never mind.

Using (or not using) O_DIRECT is not only about safety. So I'd recommend it 
being called "directio" instead of "direct-io-safe".

Cheers,
Felipe


> -----Original Message-----
> From: Stefano Stabellini [mailto:stefano.stabellini@xxxxxxxxxxxxx]
> Sent: 03 April 2014 11:12
> To: Felipe Franciosi
> Cc: Ian Jackson; Konrad Rzeszutek Wilk; George Dunlap; xen-
> devel@xxxxxxxxxxxxxxxxxxxx; Ian Campbell; Stefano Stabellini;
> alex@xxxxxxxxxxx
> Subject: RE: [Xen-devel] [PATCH] libxl: introduce an option for disabling the
> non-O_DIRECT workaround [and 1 more messages]
> 
> Ian Jackson,
> reading the thread again, it looks like the original patch is correct as it 
> is. Few
> minor modifications were suggested but they are not really required.
> 
> I think we should check it in as is now. Maybe even consider it for a 
> backport.
> 
> Are you going to take care of it?
> 
> Thanks,
> 
> Stefano
> 
> On Wed, 2 Apr 2014, Felipe Franciosi wrote:
> > A little bump on this:
> >
> > Yesterday I ran into a situation where I couldn't possibly get qemu to use
> O_DIRECT when starting a VM through xl. Using O_DIRECT is obviously
> desirable when comparing storage solutions (from disk configurations to
> virtualisation data paths) as it allows control over the workload that is 
> being
> sent to disk (and other cases).
> >
> > I can see this thread got abandoned when you reached the conclusion that
> you couldn't have a flag/option that would ensure O_DIRECT is used (or not)
> in view of some backends not supporting this configuration.
> >
> > But does it really have to be a flag that ensures O_DIRECT is used?
> >
> > I imagine we can have a "hint" flag instead. Something that hints the
> backend to use O_DIRECT. If configurable, the backend will follow this 
> setting.
> If not, it will ignore it. For example, blkback (as it is) cannot cache 
> anything, so
> it always submits requests straight to the block layer as they come. On the
> other hand, tapdisk could use O_DIRECT or not (it currently always use it).
> Qemu already supports it (through the xenstore key "direct-io-safe" in the
> Xen case).
> >
> > Thoughts on this?
> >
> > Cheers,
> > Felipe
> >
> > > -----Original Message-----
> > > From: xen-devel-bounces@xxxxxxxxxxxxx [mailto:xen-devel-
> > > bounces@xxxxxxxxxxxxx] On Behalf Of Ian Jackson
> > > Sent: 28 November 2013 17:33
> > > To: Konrad Rzeszutek Wilk; George Dunlap;
> > > xen-devel@xxxxxxxxxxxxxxxxxxxx; Ian Campbell; Stefano Stabellini;
> > > alex@xxxxxxxxxxx
> > > Subject: Re: [Xen-devel] [PATCH] libxl: introduce an option for
> > > disabling the non-O_DIRECT workaround [and 1 more messages]
> > >
> > > Ian Jackson writes ("Re: [Xen-devel] [PATCH] libxl: introduce an
> > > option for disabling the non-O_DIRECT workaround [and 1 more
> messages]"):
> > > > But maybe the tristate is a reasonable suggestion.
> > >
> > > I remember why we didn't do this.  We could implement
> > >   no-direct-io-safe
> > > or something, but it wouldn't be always effective.  It would only
> > > work for the bits of the system that we can prevent from doing O_DIRECT.
> > >
> > > Ian.
> > >
> > > _______________________________________________
> > > Xen-devel mailing list
> > > Xen-devel@xxxxxxxxxxxxx
> > > http://lists.xen.org/xen-devel
> >

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel