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@xxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
