public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Matthias Schniedermeyer <ms@citd.de>
To: Mathias Buren <mathias.buren@ie.ibm.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: RAID + LUKS + LVM performance
Date: Thu, 11 Mar 2010 18:36:04 +0100	[thread overview]
Message-ID: <20100311173604.GA17659@citd.de> (raw)
In-Reply-To: <OF8365E100.57191C87-ON802576E3.0046BDEA-802576E3.0047EFDF@ie.ibm.com>

On 11.03.2010 13:08, Mathias Buren wrote:
> 
> Hi,
> 
> (please cc me as I'm not subscribed)
> 
> I've a friend who's going to set up a fileserver consisting of 8x 1.5TB
> HDDs, an 8-port PCI-E RAID card (Areca ARC-1220 @
> http://www.areca.com.tw/products/pcie.htm ) etc.
> The plan is create a RAID5 array spanning all the disks, then create 4
> partitions. These 4 partitions would be encrypted using LUKS (Twofish or
> AES256).
> These 4 encrypted partition would be set up in RAID0 using Linux' software
> (mdadm), then LVM would be used on top of that (one big PV, one big VG and
> a big LV or so).
> 
> The reason for this is that kcryptd is not multithreaded (afaik). By having
> 4 encrypted partitions, then md0 on top of them, I'm forcing 4 kcryptd
> processes to run on all four cpu cores whenever something is written to the
> disks, which should improve (encryption) performance.
> 
> Is this a good way of doing it, or is there a smarter way?

The setup you describe would only work with SSDs. HDDs would seek 
themselves to death.

The problem is the RAID-0 over the 4 partitions. At that point you would 
need, instead of the 4 partitions, something that is round-robin. So 
that the mapping of the (physical) blocks from the upper to the lower 
would be effectivly linear/unchanged.

AFAIK something like that is (currently) not possible.





Bis denn

-- 
Real Programmers consider "what you see is what you get" to be just as 
bad a concept in Text Editors as it is in women. No, the Real Programmer
wants a "you asked for it, you got it" text editor -- complicated, 
cryptic, powerful, unforgiving, dangerous.


  reply	other threads:[~2010-03-11 17:47 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-11 13:08 RAID + LUKS + LVM performance Mathias Buren
2010-03-11 17:36 ` Matthias Schniedermeyer [this message]
2010-03-11 17:51   ` david
2010-03-11 19:07     ` Matthias Schniedermeyer
2010-03-12  8:47   ` Mathias Buren
2010-03-12 12:06     ` Matthias Schniedermeyer
2010-03-12 13:12       ` Milan Broz
2010-03-12 15:46         ` Matthias Schniedermeyer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100311173604.GA17659@citd.de \
    --to=ms@citd.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathias.buren@ie.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox