From: Christoph Hellwig <hch@infradead.org>
To: Dave Chinner <david@fromorbit.com>, torvalds@linux-foundation.org
Cc: Dmitry Monakhov <dmonlist@gmail.com>,
Theodore Ts'o <tytso@mit.edu>,
Ext4 Developers List <linux-ext4@vger.kernel.org>,
linux-fsdevel@vger.kernel.org, linux-api@vger.kernel.org
Subject: O_DIRECT as a hint, was: Re: [PATCH] ext4: refuse O_DIRECT opens for mode where DIO doesn't work
Date: Tue, 26 Apr 2016 01:14:51 -0700 [thread overview]
Message-ID: <20160426081451.GA25616@infradead.org> (raw)
In-Reply-To: <20160425234946.GB26977@dastard>
On Tue, Apr 26, 2016 at 09:49:46AM +1000, Dave Chinner wrote:
> Why not just transparently fall back to buffered IO if direct IO
> cannot be done? Saves people from wondering why applications fail
> on one ext4 filesystem and not another....
I've been doing an audit of our direct I/O implementations, and most
of them does some form of transparent fallback, including some that
only pretend to support O_DIRECT, but do anything special for it at all,
while at the same time we go through greast efforts to check a file
system actualy supports direct I/O, leading to nasty no-op ->direct_IO
implementations as we even got that abstraction wrong.
At this point I wonder if we should simply treat O_DIRECT as a hint
and always allow it, and just let the file system optimize for it
(skip buffering, require alignment, relaxed Posix atomicy requirements)
if it is set.
next parent reply other threads:[~2016-04-26 8:14 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1461472078-20104-1-git-send-email-tytso@mit.edu>
[not found] ` <877ffmhvzt.fsf@openvz.org>
[not found] ` <20160425234946.GB26977@dastard>
2016-04-26 8:14 ` Christoph Hellwig [this message]
2016-04-26 15:07 ` O_DIRECT as a hint, was: Re: [PATCH] ext4: refuse O_DIRECT opens for mode where DIO doesn't work Mike Marshall
2016-04-27 2:16 ` Theodore Ts'o
2016-04-27 2:22 ` Eric Sandeen
2016-04-27 2:25 ` Dave Chinner
2016-04-27 2:27 ` Dave Chinner
2016-04-27 3:25 ` Theodore Ts'o
2016-04-27 3:37 ` Dave Chinner
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=20160426081451.GA25616@infradead.org \
--to=hch@infradead.org \
--cc=david@fromorbit.com \
--cc=dmonlist@gmail.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=torvalds@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).