Hi Eugen,
Yes, You got it right, even though I cannot tell for sure if the
optimal_io_size is reported by the enclosure (bridge) or the usb 3.0
uas(p) kernel implementation. Afterall I am just a user ;-).
Anyhow, I think I read some slides from meetings, where voices arised,
that the IO-Hinting needs to be worked over - think about non rotational
disks, think about NVMe with huge queue-depths and and huge number of
queues and better parallelization possibilities.
I checked on the IOCTLs, there's only IOCTLs to get IO-Hinting values.
And I am a little curious about your findings on LUKS.
Regards
-Sven
Am 10.01.2016 um 21:20 schrieb Eugen Rogoza:
Hi Eugen,
Quoting a document on IO-Hintig:
'Storage vendors can also supply "I/O hints" about a device's preferred
minimum unit for random I/O ('minimum_io_size') and streaming I/O
('optimal_io_size'). For example, these hints may correspond to a RAID
device's chunk size and stripe size respectively.'
Of course a RAIDs layout parameters and preferred IO sizes are
semantically completely different things.
As for your case:
Ignore the warning. I think the optimal IO size as in 'preferred size
for sequential streaming IO' is indeed correct and must not necessarily
be a multiple of physical sector size. The optimal IO size is owed to
the transport layer (USB protocol) constraints, to max out the BUS
bandwidth.
Cutting it down to a simple example:
Consider each frame in the transport layer can hold 1.9 physical
sectors. Stuffing only 1 sector into the frame (to keep the multiple
physical sector constraint) will lead to a significant rise in number of
frames/packets and thus overhead. And I am not even talking about
transport layers with fixed frame size where you'll loose nearly 50% of
bandwidth and therefore transfer rate.
Anyway, in your case everything seems properly aligned. I tried to find
a way to influence 'optimal_io_size', could not find anything. Changing
the parameters via sysfs does not work, maybe there are IOCTLs and a
suiting utility...
Hi Sven,
thanks for the insights. If I understand the explanation correctly (and put into simpler words), the optimal_io_size is reported by USB enclosure, not by the device itself, thus confusing the device mapper layer and causing lsbkl to show misalignment (as the dm expects optimal_io_size to be multiples of physical block size). At the same time the enclosure is supposed to reassemble the sectors from the transport frames into aligned reads/writes to the physical device, thus theoretically causing no performance degradation.
Anyway, my particular issue seems to be resolved. Thanks for that again. Although it doesn't explain why a previous LUKS-container on the same partition of the same drive connected the same way didn't throw any warnings (let me redo this test to be sure).
Just a suggestion: if DM stacking tests are currently considered to be implemented in an optimal way, I would at least appreciate an additional hint somewhere in the messages that the warnings could be due to a transport layer like USB sitting in front of the physical drive, and that they could be ignored in this case.
Cheers,
Eugen
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt
