After a bit more research, I found that this issue has been mentioned on linux-usb[1] and that Martin K. Petersen weighed in on the issue in a util-linux-ng thread[2]:
On 17 June 2015 at 01:08, Martin K. Petersen <martin.peter...@oracle.com> wrote: > There's only so much we can do about devices that report garbage. > > Also, the kernel only reports things. It is up to Karel to decide > whether to sanity check the values before he uses them. If we are going to bring it up again, I'd like to have a specific recommendation or request. More discussion below: On Mon, 2019-03-04 at 13:42 -0500, Phillip Susi wrote: > On 3/4/2019 11:50 AM, Kevin Locke wrote: >> optimal_io_size is defined in the kernel ABI[1] as "the preferred >> request size for workloads where sustained throughput is desired". In >> this case, I think it comes from scsi_disk.opt_xfer_blocks[2] which >> comes from the VPD block limits page[3] which my disk reports as 65535 >> blocks (according to sg_vpd). > > Yes, I was looking over the definition earlier in the kernel > documentation, and it seems to me that part of the definition indicates > it is simply an optimal size to transfer in, and has nothing to do with > alignment. But parted treats it as having to do with alignment, because > the same kernel documentation mentions that is what the md driver uses > the field for. Could you point me to the kernel documentation that mentions how the md driver uses optimal_io_size? >> However, whether or not this is changed in the kernel, I would argue >> it should be handled in parted. Both to support previous+current >> kernels and because I think the optimal_io_size ABI definition allows >> optimal_io_size which is not a multiple of minimum_io_size for >> transports where that truly is the case. > > Unfortunately, that means parted needs to simply ignore the value of > optimal io size as totally meaningless garbage, and I don't much like > the thought of that. If parted has always been wrong and the intended > meaning of the kernel parameter has never had anything to do with > alignment, then yes, parted needs to ignore it because it read meaning > into it that was never intended. But if it is supposed to have > something to do with optimal alignment, then md is right and usb is > wrong, and usb needs to be fixed. My current reading is that optimal_io_size has the same definition as SCSI VPD Optimal Transfer Length. It has a loosely defined meaning, but its value for any particular use is contingent on sanity checking. Do you have a particular proposal for how to improve the kernel documentation or how optimal_io_size behaves? I worked up a patch which only uses logical_to_bytes(sdp, sdkp->opt_xfer_blocks) for io_opt if it is a multiple of sdkp->physical_block_size, but I am not convinced enough that it is universally applicable to advocate for it. Any alternative suggestions? Thanks, Kevin [1]: https://www.spinics.net/lists/linux-usb/msg125988.html [2]: https://www.spinics.net/lists/util-linux-ng/msg11702.html