From: Mike Snitzer <snitzer@kernel.org>
To: Keith Busch <kbusch@meta.com>
Cc: linux-block@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org, axboe@kernel.dk, dw@davidwei.uk,
brauner@kernel.org, hch@lst.de, martin.petersen@oracle.com,
djwong@kernel.org, linux-xfs@vger.kernel.org,
viro@zeniv.linux.org.uk, Keith Busch <kbusch@kernel.org>,
linux-nfs@vger.kernel.org
Subject: Re: [PATCHv3 0/8] direct-io: even more flexible io vectors
Date: Tue, 19 Aug 2025 19:36:16 -0400 [thread overview]
Message-ID: <aKUKcCIGDc79ulZ_@kernel.org> (raw)
In-Reply-To: <20250819164922.640964-1-kbusch@meta.com>
On Tue, Aug 19, 2025 at 09:49:14AM -0700, Keith Busch wrote:
> From: Keith Busch <kbusch@kernel.org>
>
> Previous version:
>
> https://lore.kernel.org/linux-block/20250805141123.332298-1-kbusch@meta.com/
>
> This series removes the direct io requirement that io vector lengths
> align to the logical block size.
>
> I tested this on a few raw block device types including nvme,
> virtio-blk, ahci, and loop. NVMe is the only one I tested with 4k
> logical sectors; everything else was 512.
>
> On each of those, I tested several iomap filesystems: xfs, ext4, and
> btrfs. I found it interesting that each behave a little
> differently with handling invalid vector alignments:
>
> - XFS is the most straight forward and reports failures on invalid
> vector conditions, same as raw blocks devices.
>
> - EXT4 falls back to buffered io for writes but not for reads.
>
> - BTRFS doesn't even try direct io for any unusual alignments; it
> chooses buffered io from the start.
>
> So it has been a little slow going figuring out which results to expect
> from various tests, but I think I've got all the corner cases covered. I
> can submit the tests cases to blktests and fstests for consideration
> separately, too.
>
> I'm not 100% sure where we're at with the last patch. I think Mike
> initially indicated this was okay to remove, but I could swear I read
> something saying that might not be the case anymore. I just can't find
> the message now. Mike?
Hey,
Yes, I don't have pointers immediately available but I did mention it
and cc'd you. I have found that my work relative to NFS and NFSD does
still need to use iov_iter_aligned_bvec -- otherwise misaligned DIO
can get issued to the underlying filesystem.
I did try to push all the relevant checking down to NFS/NFSD code that
assembles their respective bvec into an iov_iter, like you suggested,
but came up short after my first attempt.
I don't want to speak for the NFS or NFSD miantainers, but I'm
personally still OK with the broader iov_iter_is_aligned() interface
and even iov_iter_aligned_bvec() going away (and NFS/NFSD carrying
their own until I can circle back to hopefully eliminating the need).
Either that, or we remove all but iov_iter_aligned_bvec() and export
it so that NFS/NFSD can use it, _and_ tweak it so that it offers more
coarse-grained length checking, like so:
https://lore.kernel.org/linux-nfs/20250708160619.64800-5-snitzer@kernel.org/
(this is probably the best intermediate solution actually, though it'd
force my NFS and NFSD changes to be dependent on your series landing
-- which is probably a perfectly appropriate constraint)
Thanks,
Mike
>
> Changes from v2:
>
> Include vector lengths when validating a split. The length check is
> only valid for r/w commands, and skipped for passthrough
> DRV_IN/DRV_OUT commands.
>
> Introduce a prep patch having bio_iov_iter_get_pages() take the
> caller's desired length alignment.
>
> Additional code comments explaing less obvious error conditions.
>
> Added reviews on the patches that haven't changed.
>
> Keith Busch (8):
> block: check for valid bio while splitting
> block: add size alignment to bio_iov_iter_get_pages
> block: align the bio after building it
> block: simplify direct io validity check
> iomap: simplify direct io validity check
> block: remove bdev_iter_is_aligned
> blk-integrity: use simpler alignment check
> iov_iter: remove iov_iter_is_aligned
>
> block/bio-integrity.c | 4 +-
> block/bio.c | 64 ++++++++++++++++++----------
> block/blk-map.c | 2 +-
> block/blk-merge.c | 20 +++++++--
> block/fops.c | 13 +++---
> fs/iomap/direct-io.c | 6 +--
> include/linux/bio.h | 13 ++++--
> include/linux/blkdev.h | 20 +++++----
> include/linux/uio.h | 2 -
> lib/iov_iter.c | 95 ------------------------------------------
> 10 files changed, 94 insertions(+), 145 deletions(-)
>
> --
> 2.47.3
>
next prev parent reply other threads:[~2025-08-19 23:36 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-19 16:49 [PATCHv3 0/8] direct-io: even more flexible io vectors Keith Busch
2025-08-19 16:49 ` [PATCHv3 1/8] block: check for valid bio while splitting Keith Busch
2025-08-20 7:02 ` Damien Le Moal
2025-08-20 14:25 ` Keith Busch
2025-08-20 7:04 ` Damien Le Moal
2025-08-25 7:35 ` Christoph Hellwig
2025-08-19 16:49 ` [PATCHv3 2/8] block: add size alignment to bio_iov_iter_get_pages Keith Busch
2025-08-25 7:36 ` Christoph Hellwig
2025-08-19 16:49 ` [PATCHv3 3/8] block: align the bio after building it Keith Busch
2025-08-20 7:07 ` Damien Le Moal
2025-08-25 7:46 ` Christoph Hellwig
2025-08-25 13:57 ` Keith Busch
2025-08-25 7:47 ` Christoph Hellwig
2025-08-26 0:37 ` Keith Busch
2025-08-26 8:02 ` Christoph Hellwig
2025-08-26 23:11 ` Keith Busch
2025-08-19 16:49 ` [PATCHv3 4/8] block: simplify direct io validity check Keith Busch
2025-08-25 7:48 ` Christoph Hellwig
2025-08-19 16:49 ` [PATCHv3 5/8] iomap: " Keith Busch
2025-08-25 7:48 ` Christoph Hellwig
2025-08-19 16:49 ` [PATCHv3 6/8] block: remove bdev_iter_is_aligned Keith Busch
2025-08-25 7:48 ` Christoph Hellwig
2025-08-19 16:49 ` [PATCHv3 7/8] blk-integrity: use simpler alignment check Keith Busch
2025-08-25 7:49 ` Christoph Hellwig
2025-08-19 16:49 ` [PATCHv3 8/8] iov_iter: remove iov_iter_is_aligned Keith Busch
2025-08-25 7:50 ` Christoph Hellwig
2025-08-19 23:36 ` Mike Snitzer [this message]
2025-08-20 1:52 ` [PATCHv3 0/8] direct-io: even more flexible io vectors Song Chen
2025-08-22 13:27 ` Ritesh Harjani
2025-08-22 14:30 ` Keith Busch
2025-08-25 12:07 ` Jan Kara
2025-08-25 14:53 ` Keith Busch
2025-08-26 4:59 ` Ritesh Harjani
2025-08-27 15:20 ` Jan Kara
2025-08-27 16:09 ` Mike Snitzer
2025-09-01 7:55 ` Jan Kara
2025-09-02 14:39 ` Mike Snitzer
2025-08-27 17:52 ` Brian Foster
2025-08-27 19:20 ` Keith Busch
2025-09-01 8:22 ` Jan Kara
2025-08-29 2:11 ` Ritesh Harjani
2025-08-29 3:19 ` Ritesh Harjani
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=aKUKcCIGDc79ulZ_@kernel.org \
--to=snitzer@kernel.org \
--cc=axboe@kernel.dk \
--cc=brauner@kernel.org \
--cc=djwong@kernel.org \
--cc=dw@davidwei.uk \
--cc=hch@lst.de \
--cc=kbusch@kernel.org \
--cc=kbusch@meta.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=viro@zeniv.linux.org.uk \
/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.