From: Josef Bacik <jbacik@fusionio.com>
To: Dave Chinner <david@fromorbit.com>
Cc: Theodore Ts'o <tytso@mit.edu>, Josef Bacik <JBacik@fusionio.com>,
"lsf-pc@lists.linux-foundation.org"
<lsf-pc@lists.linux-foundation.org>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>
Subject: Re: [ATTEND] [LSF TOPIC] What to do about O_DIRECT?
Date: Mon, 21 Jan 2013 09:35:53 -0500 [thread overview]
Message-ID: <20130121143553.GB2276@localhost.localdomain> (raw)
In-Reply-To: <20130120223521.GE2498@dastard>
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
next prev parent reply other threads:[~2013-01-21 14:35 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-18 22:10 [ATTEND] [LSF TOPIC] What to do about O_DIRECT? Josef Bacik
2013-01-18 22:49 ` Zach Brown
2013-01-18 23:01 ` Theodore Ts'o
2013-01-20 22:35 ` Dave Chinner
2013-01-21 14:35 ` Josef Bacik [this message]
2013-01-22 14:03 ` Jan Kara
2013-01-30 23:16 ` Dave Chinner
2013-01-31 22:41 ` Jan Kara
2013-02-05 21:51 ` Dave Chinner
2013-02-06 0:40 ` Joel Becker
2013-02-06 4:32 ` Kent Overstreet
2013-02-06 17:36 ` Jan Kara
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130121143553.GB2276@localhost.localdomain \
--to=jbacik@fusionio.com \
--cc=david@fromorbit.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=lsf-pc@lists.linux-foundation.org \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).