[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]
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |