From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.saout.de (Postfix) with ESMTPS for ; Wed, 26 Feb 2014 16:12:25 +0100 (CET) Received: from [192.168.101.6] ([77.191.95.65]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0LhjeH-1X5Xdh3mnh-00mvE5 for ; Wed, 26 Feb 2014 16:12:24 +0100 Message-ID: <530E0454.7070301@gmx.de> Date: Wed, 26 Feb 2014 16:12:20 +0100 From: =?ISO-8859-1?Q?=22C=2E_Dominik_B=F3di=22?= MIME-Version: 1.0 References: <530CD101.40101@gmx.de> <530D2E10.10707@riseup.net> In-Reply-To: <530D2E10.10707@riseup.net> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="8aGQxP77hxdi268Q6eIpo9hTNIFB68AFu" Subject: Re: [dm-crypt] dm-crypt on raid 5 - having all disks on single controller makes dm-crypt slower 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 4880 and 3156) --8aGQxP77hxdi268Q6eIpo9hTNIFB68AFu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Am 26.02.2014 00:58, schrieb shmick@riseup.net: > *only* 150 ? > there's lots of numbers here but maybe we should work backwards and KIS= > ask yourself what do you want to achieve ? > when you know the results you want and/or need (2 different things) you= > can work backwards & figure out out how to get there > do you *need* to have a certain read/write speed for your application o= r > desired conclusion in mind ? Well, yes, I'd like to have as much throughput as possible. The cpu is a quad core with HT, so could dm-crypt not utilize 4 threads when there are 4 disks in the raid5 array. An the thing is: 4 disks on controller A =3D> dm-crypt 150MB/s 2 disk on controller A, 2 disks on controller B =3D> dm-crypt 300MB/s I don't understand that behaviour. Why does it make a difference for dm-crypt if the disks sit on different controllers or not? Why should I waste speed when dm-crypt could easily utilize 4 worker threads and max out the raid5 performance? Why doesn't it do so automatically. Is there any means to make dm-crypt use 4 threads even if all 4 drives sit on a single controller? I know the simple answer would be to reverse the stack, encrypt each raid drive singularly and then put the raid5 array on top of the encrypted drives. That makes it really difficult to unlock the drives remotely (via dropbear in the initramfs), though. > do you have a recent version of cryptsetup with the benchmark option ? > that can give you an idea of in memory performance and depends on your > CPU & chosen ciphers/hashes I'm using aes-xts-plain64 with 256 key size. The benchmark shows me a throughput of 175 MB/s. I reckon the benchmark only runs a single thread, so that seems to be ok. > i didn't quite get if your RAID is a hardware or software array ? Hmmm, sorry for that oversight. Yes, it is a software raid5 array set up with mdadm. > i'll leave that to the experts ;-) Yes, indeed, I was looking for an answer from someone that knows the dm-crypt kernel code quite well. Regards, Dominik --8aGQxP77hxdi268Q6eIpo9hTNIFB68AFu Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCgAGBQJTDgRXAAoJEH57oErWeAO1gW8P/14StOjRUcpakxkstNXakWzW f9Z6d8k+abGfsWRHsv4hQe0OYeUHcKPfBLRXOwQxTEw5GXSjguqHSNSWKBITdjm7 BzPWcYH5ZgF7F7ex5GpaB0gd3G72LObzKoQzaeOHKcRsYu1o6mQtbKzZBqjsw7RL T+qZZLo5N9q9Q4DK1UIPs89jYmUkydjHD3KlNtLM7wQ6me4RvjHY4D9ncN5HIHpH VRGzgF/rAQRTwvpG7hiyRpoPdtdvpfb0YnkNfDslz8bIdpkNK2OykK4BPAQnqtgT ol3ynMlRpDHUW8V8lIFVo+eAIvxH5xGRCTLu1i0ZQZcdC9Zwc1rrzwvJc6RSOlsy DhyUQSTMzwYeJU8fSjp2TiGUKSW6bjRdWNeqHL6FHiIlMKFe+aM2mxrGu1AKA1nK gWUfZpATBHKOB9VEsc8ITNOU4Qcm4n1pb5YBeQezoFP4oR1mWQGt+4zxNN/ADsUr knC5IUNdJheVWx0IpPelADDAzOXO13Mg6B6nOoD/+uuj2kyybH/eBWPTkNQKjg00 p65GVbQO+IJNM8aKEBm9TnSIqy224Dv6KePv4XaSPlE9W+48yjDKYTRfLRvrwvVp 4nxtjhyo3d/+aWMLoBNM5Ljvtwm0flhgZeTD46D47Pa0MZFVWhsA6W5utAn+d6tP kVFKYq9XBCpptFiMzQMV =zvf2 -----END PGP SIGNATURE----- --8aGQxP77hxdi268Q6eIpo9hTNIFB68AFu--