All of lore.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.