Re: [ATTEND] [LSF TOPIC] What to do about O_DIRECT?

[Joel Becker <jlbec@evilplan.org>]

On Wed, Feb 06, 2013 at 08:51:12AM +1100, Dave Chinner wrote:
> The advantage of using shared code is that it eases the burden of
> maintenance and enhancement on individual filesystems.  Both Josef
> and I are putting forward the argument that the shared direct IO
> code provides neither of those advantages any more due to current
> complexity and fragility that has resulted from the monolithic
> "everything for everyone" approach we currently have.
> 
> What I'm trying to say is that maybe there's a better way of
> providing generic direct IO support. Perhaps we are better served by
> having smaller generic helpers similar to the buffered IO path to
> allow filesystems to the simple stuff as optimally as possible
> without all the overhead they don't need. One-size-fits-all has
> never worked in the filesystems game, yet we seem to be stuck on
> that approach here even when it appears to be collapsing under it's
> own weight.... :/

	I vote for trying the helper approach.  I think dropping generic
code altogether would be a disaster.  The corner cases of O_DIRECT are
legion; everyone has behavioral assumptions based on historical
implementations, etc.  Remember how badly some high-performance software
handles O_DIRECT alignments larger than 512B.
	We have a long history of successfully inverting the generic
code with helpers and (if necessary, I'm not saying it is) operations
structures.
	I don't think I'd try to shove down generic_aio_read/write.  Let
them handle the check for O_DIRECT and the fallback to buffered I/O.

Joel


-- 

"And yet I fight,
 And yet I fight this battle all alone.
 No one to cry to;
 No place to call home."

			http://www.jlbec.org/
			jlbec@evilplan.org