On Mon, 2019-03-04 at 10:01 -0500, Phillip Susi wrote: > Interesting. It sounds like USB and MD are using optimal_io_size in > fundamentally incompatible ways. The question then is: is USB doing the > wrong thing ( and should be fixed ), or is the very definition of > optimal_io_size fundamentally broken?
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). The definition seems reasonable, but it would not surprise me if 65535 were bogus. I am not familiar enough with USB+UAS to know if this might be an optimal size for the protocols involved. I can raise the issue on linux-scsi/linux-usb. 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. Best, Kevin P.S. libfdisk from util-linux has also applied the same fix as cryptsetup of ignoring optimal_io_size if it is not a multiple of minimum_io_size.[4] [1]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/ABI/testing/sysfs-block?h=v5.0#n134 [2]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/scsi/sd.c?h=v5.0#n3137 [3]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/scsi/sd.c?h=v5.0#n2886 [4]: https://github.com/karelzak/util-linux/commit/acb7651f8