Path: csiph.com!weretis.net!feeder8.news.weretis.net!news.samoylyk.net!gothmog.csi.it!bofh.it!news.nic.it!robomod From: Filippo Giunchedi Newsgroups: linux.debian.bugs.dist,linux.debian.kernel Subject: Bug#1121006: linux: reported optimal_io_size from mpt3sas devices results in 4GB raid10 optimal_io_size Date: Thu, 20 Nov 2025 16:00:01 +0100 Message-ID: References: X-Mailbox-Line: From debian-bugs-dist-request@lists.debian.org Thu Nov 20 14:51:10 2025 Old-Return-Path: X-Spam-Flag: NO X-Spam-Score: -1.9 Reply-To: Filippo Giunchedi , 1121006@bugs.debian.org Resent-To: debian-bugs-dist@lists.debian.org Resent-Cc: debian-kernel@lists.debian.org X-Debian-Pr-Message: followup 1121006 X-Debian-Pr-Package: src:linux X-Debian-Pr-Keywords: moreinfo X-Debian-Pr-Source: linux MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: Debian GNU/Linux 5.10.0-33-amd64 X-Editor: VIM - Vi IMproved 8.2 Organization: (null) X-Greylist: delayed 398 seconds by postgrey-1.37 at buxtehude; Thu, 20 Nov 2025 14:50:06 UTC X-Debian-Message: from BTS X-Mailing-List: archive/latest/1937766 List-ID: List-URL: Approved: robomod@news.nic.it Lines: 92 Sender: robomod@news.nic.it X-Original-Cc: 1121006@bugs.debian.org X-Original-Date: Thu, 20 Nov 2025 14:43:24 +0000 X-Original-Message-ID: X-Original-References: Xref: csiph.com linux.debian.bugs.dist:1270935 linux.debian.kernel:90169 Hello Salvatore, Thank you for the quick reply. On Wed, Nov 19, 2025 at 05:59:48PM +0100, Salvatore Bonaccorso wrote: [...] > > Capabilities: [348] Vendor Specific Information: ID=0001 Rev=1 Len=038 > > Capabilities: [380] Data Link Feature > > Kernel driver in use: mpt3sas > > This sounds like quite an intersting finding but probably hard to > reproduce without the hardware if it comes to be specific to the > controller type and driver. That's a great point re: reproducibility, and it got me curious on something I hadn't thought of testing. Namely if there's another angle to this: does any block device with the same block I/O hints exhibit the same problem? The answer is actually "yes". I used qemu 'scsi-hd' device to set the same values to be able to test locally. On an already-installed VM I added the following to present four new devices: -device virtio-scsi-pci,id=scsi0 -drive file=./workdir/disks/disk3.qcow2,format=qcow2,if=none,id=drive3 -device scsi-hd,bus=scsi0.0,drive=drive3,physical_block_size=4096,logical_block_size=512,min_io_size=4096,opt_io_size=16773120 -drive file=./workdir/disks/disk4.qcow2,format=qcow2,if=none,id=drive4 -device scsi-hd,bus=scsi0.0,drive=drive4,physical_block_size=4096,logical_block_size=512,min_io_size=4096,opt_io_size=16773120 -drive file=./workdir/disks/disk5.qcow2,format=qcow2,if=none,id=drive5 -device scsi-hd,bus=scsi0.0,drive=drive5,physical_block_size=4096,logical_block_size=512,min_io_size=4096,opt_io_size=16773120 -drive file=./workdir/disks/disk6.qcow2,format=qcow2,if=none,id=drive6 -device scsi-hd,bus=scsi0.0,drive=drive6,physical_block_size=4096,logical_block_size=512,min_io_size=4096,opt_io_size=16773120 I used 10G files with 'qemu-img create -f qcow2 10G' though size doesn't affect anything in my testing. Then in the VM: # cat /sys/block/sd[cdef]/queue/optimal_io_size 16773120 16773120 16773120 16773120 # mdadm --create /dev/md1 --level 10 --bitmap none --raid-devices 4 /dev/sdc /dev/sdd /dev/sde /dev/sdf mdadm: Defaulting to version 1.2 metadata mdadm: array /dev/md1 started. # cat /sys/block/md1/queue/optimal_io_size 4293918720 I was able to reproduce the problem with src:linux 6.18~rc6-1~exp1 as well as 6.12.57-1. Since it is easy to test this way I tried with a few different opt_io_size values and was able to reproduce only with 16773120 (i.e. 0xFFF000). > I would like to ask: Do you have the possibility to make an OS > instalaltion such that you can freely experiment with various kernels > and then under them assemble the arrays? If so that would be great > that you could start bisecting the changes to find where find changes. > > I.e. install the OS independtly on the controller, find by bisecting > Debian versions manually the kernels between bookworm and trixie > (6.1.y -> 6.12.y to narrow down the upsream range). Yes I'm able to perform testing on this host, in fact I worked around the problem for now by disabling LVM's md alignment auto detection and thus we have an installed system. For reference that's "devices { data_alignment_detection = 0 }" in lvm's config. > Then bisect the ustream changes to find the offending commits. Let me > know if you need more specific instructions on the idea. Having pointers on how the recommended way to build Debian kernels would be of great help, thank you! > Additionally it would be interesting to know if the issue persist in > 6.17.8 or even 6.18~rc6-1~exp1 to be able to clearly indicate upstream > that the issue persist in upper kernels. > > Idealy actually this goes asap to upstream once we are more confident > ont the subsystem to where to report the issue. If we are reasonably > confident it it mpt3sas specific already then I would say to go > already to: Given the qemu-based reproducer above, maybe this issue is actually two bugs: raid10 as per above, and mpt3sas presenting 0xFFF000 as optimal_io_size. While the latter might be suspicious maybe it is not wrong per-se though? best, Filippo