From mboxrd@z Thu Jan 1 00:00:00 1970 From: Josef Bacik Subject: Re: [ATTEND] [LSF TOPIC] What to do about O_DIRECT? Date: Mon, 21 Jan 2013 09:35:53 -0500 Message-ID: <20130121143553.GB2276@localhost.localdomain> References: <20130118221007.GA2276@localhost.localdomain> <20130118230128.GA15758@thunk.org> <20130120223521.GE2498@dastard> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: Theodore Ts'o , Josef Bacik , "lsf-pc@lists.linux-foundation.org" , "linux-fsdevel@vger.kernel.org" To: Dave Chinner Return-path: Received: from mx1.fusionio.com ([66.114.96.30]:58136 "EHLO mx1.fusionio.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753015Ab3AUOf4 (ORCPT ); Mon, 21 Jan 2013 09:35:56 -0500 Content-Disposition: inline In-Reply-To: <20130120223521.GE2498@dastard> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Sun, Jan 20, 2013 at 03:35:21PM -0700, Dave Chinner wrote: > On Fri, Jan 18, 2013 at 06:01:28PM -0500, Theodore Ts'o wrote: > > .... and can we get rid of this horrible hack where we have this > > bastardized use of a struct buffer_head which is allocated on the > > stack, which has nothing really to do with a buffer head, and is all > > about the fact that no one wants to change the function signature for > > get_block_t? > > I have patches to do that, but they are on the back burner right now > because it causes some kind of weird corruption in the pwritev case > that kvm uses to issue IO (i.e. large iovecs of 4k segments). > > IMO, the direct IO code is that complex and convoluted now that t is > close to impossible to modify without introduce some weird, subtle > and almost impossible to debug issue. The code has been optimised to > the point of being unmaintainable, and I have seriously considered > just reimplementing the bits XFS needs just for XFS several times in > the past year.... > Yeah this is the point that I'm at currently, and it's even worse for Btrfs since we have to short circuit most of the work that the generic stuff does already since we build bio's ourselves. So maybe it would be best that we trim the generic stuff down to it's most basic functionality and leave it in place for things like ext2/3, and then for the more advanced file systems we just all do our own things. If we can all take a good look at what we would need to replace maybe we can come up with some generic helpers. Thanks, Josef