From: Matthew Wilcox <willy@infradead.org>
To: Daniel Black <daniel@mariadb.org>
Cc: linux-fsdevel@vger.kernel.org
Subject: Re: fcntl(fd, F_SETFL, O_DIRECT) succeeds followed by EINVAL in write
Date: Wed, 26 Jan 2022 22:15:00 +0000 [thread overview]
Message-ID: <YfHH5HsynuMuFJse@casper.infradead.org> (raw)
In-Reply-To: <CABVffEPReS0d1dN2eKCry_k6K0LCGNNjGf04O3c7-h6P1Q_9zg@mail.gmail.com>
On Thu, Jan 27, 2022 at 09:03:36AM +1100, Daniel Black wrote:
> On Wed, Jan 26, 2022 at 2:02 PM Matthew Wilcox <willy@infradead.org> wrote:
> >
> > On Wed, Jan 26, 2022 at 09:05:48AM +1100, Daniel Black wrote:
> >
> > O_RDONLY is defined to be 0, so don't worry about it.
>
> Thanks.
>
> > > The kernel code in setfl seems to want to return EINVAL for
> > > filesystems without a direct_IO structure member assigned,
> > >
> > > A noop_direct_IO seems to be used frequently to just return EINVAL
> > > (like cifs_direct_io).
> >
> > Sorry for the confusion. You've caught us mid-transition. Eventually,
> > ->direct_IO will be deleted, but for now it signifies whether or not the
> > filesystem supports O_DIRECT, even though it's not used (except in some
> > scenarios you don't care about).
>
> Is it going to be reasonable to expect fcntl(fd, F_SETFL, O_DIRECT) to
> return EINVAL if O_DIRECT isn't supported?
That is a reasonable expectation. I can't guarantee that we won't have
bugs, of course ...
> > > Lastly on the list of peculiar behaviors here, is tmpfs will return
> > > EINVAL from the fcntl call however it works fine with O_DIRECT
> > > (https://bugs.mysql.com/bug.php?id=26662). MySQL (and MariaDB still
> > > has the same code) that currently ignores EINVAL, but I'm willing to
> > > make that code better.
> >
> > Out of interest, what behaviour do you _want_ from doing O_DIRECT
> > to tmpfs? O_DIRECT is defined to bypass the page cache, but tmpfs
> > only stores data in the page cache. So what do you intend to happen?
>
> It occurs to me because EINVAL is returned, it's just operating in
> non-O_DIRECT mode.
>
> It occurs to me that someone probably added this because (too much)
> MySQL/MariaDB
> testing is done on tmpfs and someone didn't want to adjust the test
> suite to handle
> failures everywhere on O_DIRECT. I don't think there was any kernel
> expectation there.
>
> My problem it seems, I'll see what I can do to get back to using real
> filesystems more.
Heh. I know Hugh is looking at "supporting" O_DIRECT on tmpfs, at least
for his internal testing. Not sure what his plans are for merging
that support.
next prev parent reply other threads:[~2022-01-26 22:15 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-25 22:05 fcntl(fd, F_SETFL, O_DIRECT) succeeds followed by EINVAL in write Daniel Black
2022-01-26 3:02 ` Matthew Wilcox
2022-01-26 22:03 ` Daniel Black
2022-01-26 22:15 ` Matthew Wilcox [this message]
2022-01-26 23:16 ` Daniel Black
2022-01-27 2:38 ` Daniel Black
2022-01-27 4:37 ` Matthew Wilcox
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=YfHH5HsynuMuFJse@casper.infradead.org \
--to=willy@infradead.org \
--cc=daniel@mariadb.org \
--cc=linux-fsdevel@vger.kernel.org \
/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).