From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756600AbcAMKRm (ORCPT ); Wed, 13 Jan 2016 05:17:42 -0500 Received: from mout.kundenserver.de ([212.227.17.13]:64247 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751225AbcAMKRh (ORCPT ); Wed, 13 Jan 2016 05:17:37 -0500 From: Arnd Bergmann To: Mikulas Patocka Cc: device-mapper development , Mark Brown , Milan Broz , Jens Axboe , keith.busch@intel.com, linux-raid@vger.kernel.org, martin.petersen@oracle.com, Mike Snitzer , Baolin Wang , linux-block@vger.kernel.org, neilb@suse.com, LKML , sagig@mellanox.com, tj@kernel.org, dan.j.williams@intel.com, Kent Overstreet , Alasdair G Kergon Subject: Re: [dm-devel] [PATCH v2 0/2] Introduce the bulk IV mode for improving the crypto engine efficiency Date: Wed, 13 Jan 2016 11:17:04 +0100 Message-ID: <49336038.lhIkHu2mkF@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: References: <5514385.nEhTK7fEcU@wuerfel> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:m6FpbLbjEwm4VO2WbTBtwCINTCTQ7sCV4uo/Q1IVmD85bYs7A9m 30JSDYtFVkkeeUV2sz2YzawGbHvWuQ04g1MQnrbuFr/Ac0oJqp69X05sKulx2zrjUVeDfT9 WYZ59ziESCbwiEzauVJyugA2ouXqVeGMwWrm5Dsdddg/aHptW4XJaOTxgHNtvKcQT9o5L+m lBQa3qglH1qmW7KFmo7kg== X-UI-Out-Filterresults: notjunk:1;V01:K0:Hbsxc3B7rR0=:+nW/SMRdk8hCYsQWaaaGfe yf9Ol0fEDvDegOVCnS9Kv02TGuC0wgGjbNyyXUtTFwLJRZoqxbqpZMxKziOjvq1dHbPdwU/TC ljaKBMb2vOyZCMctJqhI9kLllfMnXUmFrhGCdJXVQj5mFFn22AdZ//DtsxDbSqT0Pbi1/ecEP FwJwf2kYbj1mJCJFxmgR5XxVz/CTrw2xlHd0Wi8NLUE+u2QwgZQqKqI2Mv2xqtwqiwpKO16l4 RhgbE5YZTl1+OBhBlEzKrW8EZeivlWAIYFSEnvCAWu2CN0M+l37Xn6gu3OKV+hUsHO4w7fQ2U 3ntruuAKBGgeMLFJjdPTnpZntofyD5vCyYrIzUwGemhf/J2FFp4dNq05IhvUtb4AsS6sj0xtc pz8SKBECgTVGZJLW8EziuX1fBdTiVP5s5AJy9T/B2mUeH3Vnc/HOkJCwqOXWCgUz+9YTi5lte nYFpr8CD56Kn9+8W43ElA/6utCVUHj/iJcKqG2mk8zoKOPH51RJpY2SRUIZnlIRIUNp9A8H5b crvOTPK7p5XH67+8JF1qC3WqKEoi04UY0TLcesLLSdbaUxf9J6utqACm3B2ElZTHm7zAVRzly PCyyBqJK49T6rUgNworvOxEQnb14jaW18oEXys7jwFuVcsuTrJ0A1r6tH04nrw5+iDnpXJKli 9SnMeoHiOWRQ8ZKLvt5pE5uNsQ+UMBrd8ZMs+1oADFYjueWwBUdi7N4+iq6hHU9V/6oPFuzsc VwJ5Aut7dI3jOtFl Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tuesday 12 January 2016 21:18:12 Mikulas Patocka wrote: > On Wed, 13 Jan 2016, Arnd Bergmann wrote: > > > On Tuesday 12 January 2016 18:31:19 Mikulas Patocka wrote: > > > > > > Another possibility is to use dm-crypt block size 4k and use a filesystem > > > with 4k blocksize on it (it will never send requests not aligned on 4k > > > boundary, so we could reject such requests with an error). > > > > Is there ever a reason to use something other than 4K block size on > > dm-crypt? > > > > Arnd > > You can't use 4k block on CBC (and most other encryption modes). If only a > part of 4k block is written (and then system crash happens), CBC would > corrupt the block completely. > > For example, suppose that EXT2 directory block is updated, the first > 512-byte sector is written and the rest of the sectors is not written > because of a crash. CBC would corrupt all sectors except the first one in > this case. > > You could use 4k block on XTS and ECB. Ah, I did not know that ext2 was doing sub-block writes. This may be something to address in the ext4 code (and other file systems), as a lot of flash storage devices (SD cards and eMMC) get really slow when you do writes smaller than 4K because of the internal read-modify-write cycle. Ideally you want to always drive those using 64K writes (for reads, it doesn't matter much). For hard drives, there are still a couple of older models that have native 512 byte sectors, but the majority of new drivers also prefers 4K writes. SSDs are typically optimized for 4K writes because that is what they expect software to do, but they use larger writes internally. Arnd