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 Q5UXqbZ6t-WG for ; Fri, 22 Nov 2013 17:35:56 +0100 (CET) Received: from webmail.medent.com (webmail.medent.com [65.114.41.130]) by mail.saout.de (Postfix) with ESMTP for ; Fri, 22 Nov 2013 17:35:56 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by webmail.medent.com (Postfix) with ESMTP id DE1E721592 for ; Fri, 22 Nov 2013 11:29:58 -0500 (EST) Received: from webmail.medent.com ([127.0.0.1]) by localhost (webmail.medent.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id EqwDmtmu07ih for ; Fri, 22 Nov 2013 11:29:58 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by webmail.medent.com (Postfix) with ESMTP id 49F1C215AE for ; Fri, 22 Nov 2013 11:29:58 -0500 (EST) Received: from webmail.medent.com ([127.0.0.1]) by localhost (webmail.medent.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id RriOieRLzAcF for ; Fri, 22 Nov 2013 11:29:58 -0500 (EST) Received: from webmail.medent.com (webmail.medent.com [65.114.41.130]) by webmail.medent.com (Postfix) with ESMTP id 2579921592 for ; Fri, 22 Nov 2013 11:29:58 -0500 (EST) Date: Fri, 22 Nov 2013 11:29:57 -0500 (EST) From: Adam Boyhan Message-ID: <1083384064.30141.1385137797930.JavaMail.root@medent.com> In-Reply-To: <942152294.28287.1385136420109.JavaMail.root@medent.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_30140_526873235.1385137797930" Subject: [dm-crypt] dm-crypt + mdadm List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de ------=_Part_30140_526873235.1385137797930 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Doing allot of testing with dm-crypt and mdadm. Running into an issues which is killing me. We run a standard CentOS6 load with kernel "2.6.32-358.23.2.el6.x86_64" Scenario #1: mdadm raid10 -> dm-crypt -> ext4 Scenario #2: dm-crypt -> mdadm raid10 -> ext4 Scenario #1 has no issues and runs reliably but takes a significant hit in performance due to the single threaded nature of kryptd. I read quite a bit about people instead encrypting each block device then putting software encryption on that. This all goes well until I start to benchmark. The writing process of the benchmark goes well, as soon as I hit the read portion of the test, the machine panics and locks up. I initially tested this idea with raid0 and I don't have this panic, it seems that only raid10 causes the panic. At this point I am stumped as to what I can do. I am feel this is more an issue with mdadm than dm-crypt but I figured it was worth getting others opinions. I appreciate any or all help, if I am missing any details let me know and I will provide them. Thanks, Adam Boyhan ------=_Part_30140_526873235.1385137797930 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Doing allot of testing with dm-crypt and mdadm. Runnin= g into an issues which is killing me. We run a standard CentOS6 load = with kernel "2.6.32-358.23.2.el6.x86_64"

Sc= enario #1: mdadm raid10 -> dm-crypt -> ext4

Scenario #2: dm= -crypt -> mdadm raid10 -> ext4

Scenario #1 h= as no issues and runs reliably but takes a significant hit in performance d= ue to the single threaded nature of kryptd. I read quite a bit about = people instead encrypting each block device then putting software encryptio= n on that. This all goes well until I start to benchmark. The w= riting process of the benchmark goes well, as soon as I hit the read portio= n of the test, the machine panics and locks up. I initially tested th= is idea with raid0 and I don't have this panic, it seems that only raid10 c= auses the panic. At this point I am stumped as to what I can do. &nbs= p;I am feel this is more an issue with mdadm than dm-crypt but I figured it= was worth getting others opinions. I appreciate any or all help, if = I am missing any details let me know and I will provide them.

Thanks,
Adam Boyhan

------=_Part_30140_526873235.1385137797930--