Mikulas,
If there is some particular SSD that has more write IOPS for 8k requests
than for 4k requests, I'd like to know about it - out of curiosity.
SSD blocks are getting bigger and bigger, some drives hide it better
than others. Also look at all the efforts going on wrt. supporting
larger block sizes in the kernel.
Can you send me the output of:
# sg_vpd -p bl /dev/sdN
and maybe hdparm -I too? I'd like to see if we can come up with a
reasonable heuristic.
--
Martin K. Petersen Oracle Linux Engineering
On Tue, 4 Feb 2025, Martin K. Petersen wrote:
Mikulas,
quoted
If there is some particular SSD that has more write IOPS for 8k requests
than for 4k requests, I'd like to know about it - out of curiosity.
SSD blocks are getting bigger and bigger, some drives hide it better
than others. Also look at all the efforts going on wrt. supporting
larger block sizes in the kernel.
Can you send me the output of:
# sg_vpd -p bl /dev/sdN
and maybe hdparm -I too? I'd like to see if we can come up with a
reasonable heuristic.
--
Martin K. Petersen Oracle Linux Engineering
I don't have that USB-SATA bridge that reports optimal I/O size 65535
sectors. Milan talked about it, but maybe he doesn't have it too. Some
user reported that cryptsetup behaves badly with this particular bridge,
so Milan wrote workaround for it in cryptsetup.
You can simulate it with "modprobe scsi_debug dev_size_mb=32
sector_size=512 num_tgts=1 opt_blks=65535"
Mikulas
On 2/10/25 1:54 PM, Mikulas Patocka wrote:
...
quoted
Can you send me the output of:
# sg_vpd -p bl /dev/sdN
and maybe hdparm -I too? I'd like to see if we can come up with a
reasonable heuristic.
--
Martin K. Petersen Oracle Linux Engineering
I don't have that USB-SATA bridge that reports optimal I/O size 65535
sectors. Milan talked about it, but maybe he doesn't have it too. Some
user reported that cryptsetup behaves badly with this particular bridge,
so Milan wrote workaround for it in cryptsetup.
I think I have that adapter somewhere in the box (I guess it is JMicron thingy).
But the change in cryptsetup was based on several user reports (one was
https://gitlab.com/cryptsetup/cryptsetup/-/issues/585 but there is too
much confusion from my side :-)
We just added a rule to ignore bogus value and stay with a default
alignment in that case.
There are some links in the report, though:
https://linux-blog.anracom.com/2018/12/03/linux-ssd-partition-alignment-problems-with-external-usb-to-sata-controllers-i/
https://bugzilla.redhat.com/show_bug.cgi?id=1420935
It is an old story, apparently.
If I see it again, I can send report (or even fix) to linux-usb list,
as this is really related to USB storage driver (AFAIK).
The code below just simulated what the USB enclosure presented to kernel.
You can simulate it with "modprobe scsi_debug dev_size_mb=32
sector_size=512 num_tgts=1 opt_blks=65535"
Milan