All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Theodore Ts'o" <tytso@mit.edu>
To: Eric Biggers <ebiggers@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 4/9] ext4: support STATX_DIOALIGN
Date: Fri, 22 Jul 2022 13:05:32 -0400	[thread overview]
Message-ID: <YtrY3A/nC023v+/V@mit.edu> (raw)
In-Reply-To: <20220722071228.146690-5-ebiggers@kernel.org>

On Fri, Jul 22, 2022 at 12:12:23AM -0700, Eric Biggers wrote:
> -static bool ext4_dio_supported(struct kiocb *iocb, struct iov_iter *iter)
> +/*
> + * Returns %true if the given DIO request should be attempted with DIO, or
> + * %false if it should fall back to buffered I/O.
> + *
> + * DIO isn't well specified; when it's unsupported (either due to the request
> + * being misaligned, or due to the file not supporting DIO at all), filesystems
> + * either fall back to buffered I/O or return EINVAL.  For files that don't use
> + * any special features like encryption or verity, ext4 has traditionally
> + * returned EINVAL for misaligned DIO.  iomap_dio_rw() uses this convention too.
> + * In this case, we should attempt the DIO, *not* fall back to buffered I/O.
> + *
> + * In contrast, in cases where DIO is unsupported due to ext4 features, ext4
> + * traditionally falls back to buffered I/O.
> + *
> + * This function implements the traditional ext4 behavior in all these cases.

Heh.  I had been under the impression that misaligned I/O fell back to
buffered I/O for ext4, since that's what a lot of historical Unix
systems did.  Obviously, it's not something I've tested since "you
should never do that".

There's actually some interesting discussion about what Linux *should*
be doing in the futre in this discussion:

https://patchwork.ozlabs.org/project/linux-ext4/patch/1461472078-20104-1-git-send-email-tytso@mit.edu/

Including the following from Christoph Hellwig:

https://patchwork.ozlabs.org/project/linux-ext4/patch/1461472078-20104-1-git-send-email-tytso@mit.edu/#1335016

> 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.

The thread also mentioned XFS_IOC_DIOINFO and how We Really Should
have something with equivalent functionality to the VFS --- six years
ago.  :-)


Anyway, this change to ext4 looks good.

Acked-by: Theodore Ts'o <tytso@mit.edu>

							- Ted

WARNING: multiple messages have this Message-ID (diff)
From: "Theodore Ts'o" <tytso@mit.edu>
To: Eric Biggers <ebiggers@kernel.org>
Cc: linux-block@vger.kernel.org, linux-api@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	linux-f2fs-devel@lists.sourceforge.net,
	linux-xfs@vger.kernel.org, Keith Busch <kbusch@kernel.org>,
	linux-fscrypt@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-ext4@vger.kernel.org
Subject: Re: [f2fs-dev] [PATCH v4 4/9] ext4: support STATX_DIOALIGN
Date: Fri, 22 Jul 2022 13:05:32 -0400	[thread overview]
Message-ID: <YtrY3A/nC023v+/V@mit.edu> (raw)
In-Reply-To: <20220722071228.146690-5-ebiggers@kernel.org>

On Fri, Jul 22, 2022 at 12:12:23AM -0700, Eric Biggers wrote:
> -static bool ext4_dio_supported(struct kiocb *iocb, struct iov_iter *iter)
> +/*
> + * Returns %true if the given DIO request should be attempted with DIO, or
> + * %false if it should fall back to buffered I/O.
> + *
> + * DIO isn't well specified; when it's unsupported (either due to the request
> + * being misaligned, or due to the file not supporting DIO at all), filesystems
> + * either fall back to buffered I/O or return EINVAL.  For files that don't use
> + * any special features like encryption or verity, ext4 has traditionally
> + * returned EINVAL for misaligned DIO.  iomap_dio_rw() uses this convention too.
> + * In this case, we should attempt the DIO, *not* fall back to buffered I/O.
> + *
> + * In contrast, in cases where DIO is unsupported due to ext4 features, ext4
> + * traditionally falls back to buffered I/O.
> + *
> + * This function implements the traditional ext4 behavior in all these cases.

Heh.  I had been under the impression that misaligned I/O fell back to
buffered I/O for ext4, since that's what a lot of historical Unix
systems did.  Obviously, it's not something I've tested since "you
should never do that".

There's actually some interesting discussion about what Linux *should*
be doing in the futre in this discussion:

https://patchwork.ozlabs.org/project/linux-ext4/patch/1461472078-20104-1-git-send-email-tytso@mit.edu/

Including the following from Christoph Hellwig:

https://patchwork.ozlabs.org/project/linux-ext4/patch/1461472078-20104-1-git-send-email-tytso@mit.edu/#1335016

> 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.

The thread also mentioned XFS_IOC_DIOINFO and how We Really Should
have something with equivalent functionality to the VFS --- six years
ago.  :-)


Anyway, this change to ext4 looks good.

Acked-by: Theodore Ts'o <tytso@mit.edu>

							- Ted


_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

  reply	other threads:[~2022-07-22 17:06 UTC|newest]

Thread overview: 61+ 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 ` [f2fs-dev] " Eric Biggers
2022-07-22  7:12 ` [PATCH v4 1/9] statx: add direct I/O " Eric Biggers
2022-07-22  7:12   ` [f2fs-dev] " Eric Biggers
2022-07-22 16:32   ` Darrick J. Wong
2022-07-22 16:32     ` [f2fs-dev] " Darrick J. Wong
2022-07-22 17:31   ` Martin K. Petersen
2022-07-22 17:31     ` [f2fs-dev] " Martin K. Petersen
2022-07-22  7:12 ` [PATCH v4 2/9] vfs: support STATX_DIOALIGN on block devices Eric Biggers
2022-07-22  7:12   ` [f2fs-dev] " Eric Biggers
2022-07-22  8:10   ` Christoph Hellwig
2022-07-22  8:10     ` [f2fs-dev] " Christoph Hellwig
2022-07-22 17:32   ` Martin K. Petersen
2022-07-22 17:32     ` [f2fs-dev] " 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  7:12   ` [f2fs-dev] " Eric Biggers
2022-07-22  8:10   ` Christoph Hellwig
2022-07-22  8:10     ` [f2fs-dev] " Christoph Hellwig
2022-07-22  7:12 ` [PATCH v4 4/9] ext4: support STATX_DIOALIGN Eric Biggers
2022-07-22  7:12   ` [f2fs-dev] " Eric Biggers
2022-07-22 17:05   ` Theodore Ts'o [this message]
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   ` [f2fs-dev] " 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-22  7:12   ` [f2fs-dev] " Eric Biggers
2022-07-24  2:01   ` Jaegeuk Kim
2022-07-24  2:01     ` [f2fs-dev] " Jaegeuk Kim
2022-07-25 18:12     ` Eric Biggers
2022-07-25 18:12       ` [f2fs-dev] " Eric Biggers
2022-07-25 23:58       ` Andreas Dilger
2022-07-31  3:08       ` Jaegeuk Kim
2022-07-31  3:08         ` [f2fs-dev] " Jaegeuk Kim
2022-08-16  0:55         ` Eric Biggers
2022-08-16  0:55           ` Eric Biggers
2022-08-16  9:03           ` [f2fs-dev] " Dave Chinner
2022-08-16  9:03             ` Dave Chinner
2022-08-16 16:42             ` Andreas Dilger
2022-08-19 23:09               ` Eric Biggers
2022-08-19 23:09                 ` [f2fs-dev] " Eric Biggers
2022-08-23  3:22                 ` Andreas Dilger
2022-08-20  0:06           ` Jaegeuk Kim
2022-08-20  0:06             ` [f2fs-dev] " Jaegeuk Kim
2022-08-20  0:33             ` Eric Biggers
2022-08-20  0:33               ` Eric Biggers
2022-08-21  8:53           ` Christoph Hellwig
2022-08-21  8:53             ` [f2fs-dev] " Christoph Hellwig
2022-07-22  7:12 ` [PATCH v4 7/9] f2fs: simplify f2fs_force_buffered_io() Eric Biggers
2022-07-22  7:12   ` [f2fs-dev] " Eric Biggers
2022-07-22  7:12 ` [PATCH v4 8/9] f2fs: support STATX_DIOALIGN Eric Biggers
2022-07-22  7:12   ` [f2fs-dev] " Eric Biggers
2022-07-22  7:12 ` [PATCH v4 9/9] xfs: " Eric Biggers
2022-07-22  7:12   ` [f2fs-dev] " Eric Biggers
2022-07-22  8:11   ` Christoph Hellwig
2022-07-22  8:11     ` [f2fs-dev] " Christoph Hellwig
2022-07-22 16:24   ` Darrick J. Wong
2022-07-22 16:24     ` [f2fs-dev] " Darrick J. Wong
2022-08-26 17:19 ` [PATCH v4 0/9] make statx() return DIO alignment information Jeff Layton
2022-08-26 17:19   ` [f2fs-dev] " Jeff Layton
2022-08-27  7:07   ` Eric Biggers
2022-08-27  7:07     ` [f2fs-dev] " 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=YtrY3A/nC023v+/V@mit.edu \
    --to=tytso@mit.edu \
    --cc=ebiggers@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.