[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <87a53ra3mb.fsf@gmail.com>
Date: Fri, 22 Aug 2025 18:57:08 +0530
From: Ritesh Harjani (IBM) <ritesh.list@...il.com>
To: Keith Busch <kbusch@...a.com>, linux-block@...r.kernel.org, linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org, linux-ext4@...r.kernel.org
Cc: snitzer@...nel.org, axboe@...nel.dk, dw@...idwei.uk, brauner@...nel.org, hch@....de, martin.petersen@...cle.com, djwong@...nel.org, linux-xfs@...r.kernel.org, viro@...iv.linux.org.uk, Keith Busch <kbusch@...nel.org>, Jan Kara <jack@...e.com>
Subject: Re: [PATCHv3 0/8] direct-io: even more flexible io vectors
Keith Busch <kbusch@...a.com> writes:
> From: Keith Busch <kbusch@...nel.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.
++linux-ext4 to get any historical context behind why the difference of
behaviour in reads v/s writes for EXT4 DIO.
BTW - I did some basic testing of the series against block device, XFS &
EXT4 and it worked as expected (for both DIO & AIO-DIO) i.e.
1. Individial iov_len need not be aligned to the logical block size anymore.
2. Total length of iovecs should be logical block size aligned though.
i.e. this combination works with this patch series now:
posix_memalign((void**)&aligned_buf, mem_align, 2 * BLOCK_SIZE);
struct iovec iov[4] = {
{.iov_base = aligned_buf, .iov_len = 500},
{.iov_base = aligned_buf + 500, .iov_len = 1500},
{.iov_base = aligned_buf + 2000, .iov_len = 2000},
{.iov_base = aligned_buf + 4000, .iov_len = 4192}
}; // 500 + 1500 + 2000 + 4192 = 8192
-ritesh
>
> - 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?
>
> 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
Powered by blists - more mailing lists