> 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
