[dm-crypt] Alignment issue with 4K disk

Sven Eschenberg sven at whgl.uni-frankfurt.de
Sun Jan 10 22:00:51 CET 2016

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.



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 at saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt

More information about the dm-crypt mailing list