On Sunday, 24 April 2022 00:10:01 CEST Diederik de Haas wrote: > The drives have the exact same same characteristics: > > # fdisk -l /dev/sdb > Disk /dev/sdb: 2.73 TiB, 3000592982016 bytes, 5860533168 sectors > Disk model: WDC WD30EFRX-68E > Units: sectors of 1 * 512 = 512 bytes > Sector size (logical/physical): 512 bytes / 4096 bytes > I/O size (minimum/optimal): 4096 bytes / 4096 bytes > > [ USB connected drive ] > # sg_vpd -p bl /dev/sdb > Block limits VPD page (SBC): > ... > Optimal transfer length granularity: 8 blocks > Maximum transfer length: 65535 blocks > Optimal transfer length: 65535 blocks > Maximum prefetch transfer length: 65535 blocks > <snip> > > [ SATA connected drive ] > # sg_vpd -p bl /dev/sdb > Block limits VPD page (SBC): > ... > Optimal transfer length granularity: 8 blocks > Maximum transfer length: 0 blocks [not reported] > Optimal transfer length: 0 blocks [not reported] > Maximum prefetch transfer length: 0 blocks [ignored] > <snip> Learned some more things: - partitioning is irrelevant (for this issue) - physical sector size of 4096 is very relevant; with 512 you don't get a warning, only an informational message saying 33553920 bytes is optimal transfer size (which is still 512 bytes short of 32MB) - USB connected drive reports Maximum/Optimum length of 65535 blocks, while SATA reports 0 The last item explains the difference I saw and I missed it as I was focused on the partitioning. > https://www.spinics.net/lists/linux-scsi/msg139591.html is where I got > the various `sg_*` commands from. One of that message follow-ups was titled: [PATCH] scsi: sd: Optimal I/O size should be a multiple of reported granularity After a bit of searching that led me to the following: https://patchwork.kernel.org/project/linux-scsi/patch/20220302053559.32147-9-martin.petersen@oracle.com/ or https://lkml.kernel.org/linux-scsi/20220302053559.32147-1-martin.petersen@oracle.com/ on LKML I feel a bit more comfortable ignoring the kernel warning, but I'm still not sure whether it is a harmless msg or an actual bug. If the maintainers consider this not to be a bug, feel free to close it. Cheers, Diederik
Attachment:
signature.asc
Description: This is a digitally signed message part.