From mboxrd@z Thu Jan 1 00:00:00 1970 From: Joel Becker Subject: Re: [ATTEND] [LSF TOPIC] What to do about O_DIRECT? Date: Tue, 5 Feb 2013 16:40:53 -0800 Message-ID: <20130206004051.GA12174@localhost> References: <20130118221007.GA2276@localhost.localdomain> <20130122140337.GC28331@quack.suse.cz> <20130130231600.GD32297@disturbed.disaster> <20130131224109.GC13525@quack.suse.cz> <20130205215112.GQ2667@dastard> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Jan Kara , Josef Bacik , lsf-pc@lists.linux-foundation.org, linux-fsdevel@vger.kernel.org To: Dave Chinner Return-path: Received: from zeniv.linux.org.uk ([195.92.253.2]:44060 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753729Ab3BFAlP (ORCPT ); Tue, 5 Feb 2013 19:41:15 -0500 Content-Disposition: inline In-Reply-To: <20130205215112.GQ2667@dastard> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 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