From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.saout.de ([127.0.0.1]) by localhost (mail.saout.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dLZpglpX4v0o for ; Fri, 23 Nov 2012 05:18:10 +0100 (CET) Received: from babioch.de (babioch.de [IPv6:2a01:4f8:151:7ffd::1]) by mail.saout.de (Postfix) with ESMTP for ; Fri, 23 Nov 2012 05:18:09 +0100 (CET) Received: from vpcs.babioch (unknown [188.195.232.136]) by babioch.de (Postfix) with ESMTPSA id 85FEE4007C for ; Fri, 23 Nov 2012 05:12:36 +0100 (CET) Message-ID: <50AEF7B3.4000807@babioch.de> Date: Fri, 23 Nov 2012 05:12:35 +0100 From: Karol Babioch MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig0D48C8DBBE9925B07AAD4204" Subject: [dm-crypt] Reconsidering default options for cryptsetup-reencrypt List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0D48C8DBBE9925B07AAD4204 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, I'm currently reencrypting my (hardware) RAID setup, which is quite big (12 TB) in order to change the cipher from aes-xts-plain to aes-xts-plain= 64. While playing around with various options, I found out that a block size of 64 MB and the use of direct I/O results in the highest speed for me. Now, I admit that at least the "optimal" block size depends very much on your setup and the caches and/or buffers involved. However I would argue that enabling direct I/O should be faster on most systems considering that usual block devices are probably quite big - at least compared to "normal" files and reencrypting the device is a purely consecutive process. Running some tests I could confirm my assumption. In my case where I've got a hardware RAID with read ahead enabled, it makes at least a difference of about 10%. Is there a reason why direct I/O is not enabled by default? Maybe I'm missing something obvious here? Personally I think that 10% can be quite much, especially when the process takes 24 hours and more. That said I think the bigger influence is the choice of the right block size. By choosing the right block size I could double the speed. As already said above I think it probably is quite hard to get this one right automatically for each and everyone, because it depends upon various caches involved. From a theoretical stand point it probably should be about half the size of the smallest cache involved. I'm not sure whether it makes any sense (or is even possible) to probe for these things, but considering the speed enhancement of - at least in my case - 100%, there should probably be something done about it. Now, before implementing any of this, I would like to know whether you've got similar and/or even contradicting experiences and whether there are specific reasons for the default values of the options mentioned above. Maybe I'm just generalizing too much here when trying to come up with some conclusions based on my hardware. Best regards, Karol Babioch --------------enig0D48C8DBBE9925B07AAD4204 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQIcBAEBAgAGBQJQrve0AAoJEHSaZc1HnzIVllEP/1PqJ3EAIS34YLeIihKqWfGC Pe5Bd0oEGC/NjSRNUbDK+qoYVpr6De0Z6MB2IZjG2SJ1HYRABNfqHietAvXtzuQg XbwiT8kHr+QfchU6VMOc2q73ugQUoxW3/3oVrY1P9OA8GvQyZVelDKTCLAlXOM4R 5t7zXqIBVoqFslmMBImgnze/EbtziAn0QYV5/YkWTUgKOizYfJN+ogaq8dXTGdNS lbrAfw3TzCJJlwcMeCN/7hT4EyLy3FLSmFar9BPYvphEvARZW1JVBjQ4p+0fQ7kr 0br71kn2lrhGmmcwaSAE8vcvqh0MVDcZL3GBL/Bq6xWfHlTp8MAhXFRP7SY/Vlx7 9jcS/dQqUZZh+Ozp8l9c/Q+5CMPB/WNVI3QQ45qEcGAD62xBQD1YNt8B6jlpvNGe nliufIymncVvAdaez32h20rImm7yZD1SFtRqNXa6ong7+aslFHx0pgNKisJTJTRs +n1qakVNN1KSIg2qbzEjBww017QE3C1iWVHEd24O7zl7ExYHPY98UBknhdSTr4/m fnR6/wRzaopbo+pC8tPoJbxwi1jlo3ASuaEkCBJahsnnq1SY385fdDcvMfFjq2YW A95SFXjM8LA1ZR9mUH9pjBJgbbqK/RH6KaKsATDKnTz3TP9ytICZrHL2ZnoBiWY3 aGFXJRMUBV9nUuVEb1Dx =XVP0 -----END PGP SIGNATURE----- --------------enig0D48C8DBBE9925B07AAD4204--