Thread (25 messages) 25 messages, 10 authors, 2026-04-02

Re: [PATCH v2] block: Increase BLK_DEF_MAX_SECTORS_CAP

From: Damien Le Moal <dlemoal@kernel.org>
Date: 2025-08-27 08:06:31

On 8/27/25 5:00 PM, Christoph Hellwig wrote:
On Wed, Aug 27, 2025 at 09:52:21AM +0200, Sebastian Andrzej Siewior wrote:
quoted
quoted
this for you, you could also reproduce it before by say doing a large
direct I/O read.
On a kernel without that commit in question? Booting Debian's current
v6.12 and
|  dd if=vmlinux.o of=/dev/null bs=1G count=1 iflag=direct

works like a charm. According to strace it does
| openat(AT_FDCWD, "vmlinux.o", O_RDONLY|O_DIRECT) = 3
| dup2(3, 0)                              = 0
| lseek(0, 0, SEEK_CUR)                   = 0
| read(0, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\1\0>\0\1\0\0\0\0\0\0\0\0\0\0\0"..., 1073741824) = 841980992

so it should be what you asked for. Asked for 1G, got ~800M.
This is probably splitting thing up into multiple bios because your
output memory is fragmented.  You'd have to do it into hugetlbfs or
vma otherwise backed by very larger folios.
and also need:

echo 4096 > /sys/block/sdX/queue/max_sectors_kb

or some large number.

But given that commit 345c5091ffec sets the default to 4MiB, I/Os are split to
4M and trigger the issue. So there is likely a cut-off command size < 4M where
things stop working with this adapter.


-- 
Damien Le Moal
Western Digital Research
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help