Re: [dm-crypt] Alignment issue with 4K disk

["Eugen Rogoza" <euro123@gmx.net>]

> 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