linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers@kernel.org>
To: Jaegeuk Kim <jaegeuk@kernel.org>
Cc: linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org,
	linux-f2fs-devel@lists.sourceforge.net,
	linux-xfs@vger.kernel.org, linux-api@vger.kernel.org,
	linux-fscrypt@vger.kernel.org, linux-block@vger.kernel.org,
	linux-kernel@vger.kernel.org, Keith Busch <kbusch@kernel.org>
Subject: Re: [PATCH v4 6/9] f2fs: don't allow DIO reads but not DIO writes
Date: Mon, 25 Jul 2022 11:12:25 -0700	[thread overview]
Message-ID: <Yt7dCcG0ns85QqJe@sol.localdomain> (raw)
In-Reply-To: <YtyoF89iOg8gs7hj@google.com>

On Sat, Jul 23, 2022 at 07:01:59PM -0700, Jaegeuk Kim wrote:
> On 07/22, Eric Biggers wrote:
> > From: Eric Biggers <ebiggers@google.com>
> > 
> > Currently, if an f2fs filesystem is mounted with the mode=lfs and
> > io_bits mount options, DIO reads are allowed but DIO writes are not.
> > Allowing DIO reads but not DIO writes is an unusual restriction, which
> > is likely to be surprising to applications, namely any application that
> > both reads and writes from a file (using O_DIRECT).  This behavior is
> > also incompatible with the proposed STATX_DIOALIGN extension to statx.
> > Given this, let's drop the support for DIO reads in this configuration.
> 
> IIRC, we allowed DIO reads since applications complained a lower performance.
> So, I'm afraid this change will make another confusion to users. Could
> you please apply the new bahavior only for STATX_DIOALIGN?
> 

Well, the issue is that the proposed STATX_DIOALIGN fields cannot represent this
weird case where DIO reads are allowed but not DIO writes.  So the question is
whether this case actually matters, in which case we should make STATX_DIOALIGN
distinguish between DIO reads and DIO writes, or whether it's some odd edge case
that doesn't really matter, in which case we could just fix it or make
STATX_DIOALIGN report that DIO is unsupported.  I was hoping that you had some
insight here.  What sort of applications want DIO reads but not DIO writes?
Is this common at all?

- Eric

  reply	other threads:[~2022-07-25 18:12 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-22  7:12 [PATCH v4 0/9] make statx() return DIO alignment information Eric Biggers
2022-07-22  7:12 ` [PATCH v4 1/9] statx: add direct I/O " Eric Biggers
2022-07-22 16:32   ` Darrick J. Wong
2022-07-22 17:31   ` Martin K. Petersen
2022-07-22  7:12 ` [PATCH v4 2/9] vfs: support STATX_DIOALIGN on block devices Eric Biggers
2022-07-22  8:10   ` Christoph Hellwig
2022-07-22 17:32   ` Martin K. Petersen
2022-07-22  7:12 ` [PATCH v4 3/9] fscrypt: change fscrypt_dio_supported() to prepare for STATX_DIOALIGN Eric Biggers
2022-07-22  8:10   ` Christoph Hellwig
2022-07-22  7:12 ` [PATCH v4 4/9] ext4: support STATX_DIOALIGN Eric Biggers
2022-07-22 17:05   ` Theodore Ts'o
2022-07-22  7:12 ` [PATCH v4 5/9] f2fs: move f2fs_force_buffered_io() into file.c Eric Biggers
2022-07-22  7:12 ` [PATCH v4 6/9] f2fs: don't allow DIO reads but not DIO writes Eric Biggers
2022-07-24  2:01   ` Jaegeuk Kim
2022-07-25 18:12     ` Eric Biggers [this message]
2022-07-25 23:58       ` Andreas Dilger
2022-07-31  3:08       ` Jaegeuk Kim
2022-08-16  0:55         ` Eric Biggers
2022-08-16  9:03           ` Dave Chinner
2022-08-16 16:42             ` Andreas Dilger
2022-08-19 23:09               ` Eric Biggers
2022-08-23  3:22                 ` Andreas Dilger
2022-08-20  0:06           ` Jaegeuk Kim
2022-08-20  0:33             ` Eric Biggers
2022-08-21  8:53           ` Christoph Hellwig
2022-07-22  7:12 ` [PATCH v4 7/9] f2fs: simplify f2fs_force_buffered_io() Eric Biggers
2022-07-22  7:12 ` [PATCH v4 8/9] f2fs: support STATX_DIOALIGN Eric Biggers
2022-07-22  7:12 ` [PATCH v4 9/9] xfs: " Eric Biggers
2022-07-22  8:11   ` Christoph Hellwig
2022-07-22 16:24   ` Darrick J. Wong
2022-08-26 17:19 ` [PATCH v4 0/9] make statx() return DIO alignment information Jeff Layton
2022-08-27  7:07   ` Eric Biggers

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=Yt7dCcG0ns85QqJe@sol.localdomain \
    --to=ebiggers@kernel.org \
    --cc=jaegeuk@kernel.org \
    --cc=kbusch@kernel.org \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-f2fs-devel@lists.sourceforge.net \
    --cc=linux-fscrypt@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-xfs@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).