From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.server123.net (Postfix) with ESMTPS for ; Sun, 10 Jan 2016 21:20:37 +0100 (CET) MIME-Version: 1.0 Message-ID: From: "Eugen Rogoza" Content-Type: text/plain; charset=UTF-8 Date: Sun, 10 Jan 2016 21:20:37 +0100 In-Reply-To: <5692AD3C.9070906@whgl.uni-frankfurt.de> References: , <5692AD3C.9070906@whgl.uni-frankfurt.de> Subject: Re: [dm-crypt] Alignment issue with 4K disk List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de > 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