[dm-crypt] Alignment issue with 4K disk
euro123 at gmx.net
Sun Jan 10 21:20:37 CET 2016
> 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
> 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...
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.
More information about the dm-crypt