From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mps1.wohnheimg.uni-frankfurt.de (mps1.wohnheimg.uni-frankfurt.de [141.2.118.239]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.server123.net (Postfix) with ESMTPS for ; Sun, 10 Jan 2016 22:00:51 +0100 (CET) Received: from p4fe84b79.dip0.t-ipconnect.de ([79.232.75.121] helo=[192.168.0.11]) (Authed sender Sven 'DarKRaveR' Eschenberg) by mps1.wohnheimg.uni-frankfurt.de via ESMTPSA (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim) (envelope-from ) id 1aIN6Z-0006s1-Bt for dm-crypt@saout.de; Sun, 10 Jan 2016 22:00:51 +0100 References: <5692AD3C.9070906@whgl.uni-frankfurt.de> From: Sven Eschenberg Message-ID: <5692C683.3090803@whgl.uni-frankfurt.de> Date: Sun, 10 Jan 2016 22:00:51 +0100 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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, 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. Regards -Sven 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@saout.de > http://www.saout.de/mailman/listinfo/dm-crypt >