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

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



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.