DM-Crypt Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Arno Wagner <arno@wagner.name>
To: dm-crypt@saout.de
Subject: Re: [dm-crypt] Question on Disk Layout (Stacking supported ?)
Date: Thu, 10 Mar 2011 19:57:39 +0100	[thread overview]
Message-ID: <20110310185738.GA3908@tansi.org> (raw)
In-Reply-To: <DA0E1B0401643E4E9750810C61C8697F0496AE2B@ISS-EXM1005.deutschepost.dpwn.com>

Don't know about your particlar setup, but I have several
RAID1 (including two 3-way and one with an SSD) below
dm-crypt. Works pretty well. 

The main question I see is what you want with the encrypton.
Of course, you can blanket encrypt everything, wich seems
to be what you want, except for /boot. Personally, I 
want it the other way round, but I have not allways
all encrypted devices mapped and different passphrases
for them.

Arno


On Thu, Mar 10, 2011 at 07:06:31PM +0100, Robert.Heinzmann@deutschepost.de wrote:
> Hello list, 
>  
> I have a more general question regarding dm_crypt. 
>  
>   Q: What is the best way to incorporate dm_crypt in a production ready device stack ? 
> 
> Summing I have multipathing (optional) and I want flexible storage management with pvresize, multiple filesystems and everything (e.g. in "the clouds") LVM is the way to go. So my ideal (and working) setup would look like this: 
>  
> Filesystem: [      /boot      ] [ /   ]  [ /var ]
> LVM         [                 ] [ lv1 ]  [ lv2  ]
> LVM         [                 ] [ vg (RootVG)   ]
> LVM         [                 ] [ pv            ]
> Crypt:      [                 ] [ DM_CRYPT      ] 
> Partition:  [ part1 - (boot)  ] [    part2      ]
> SCSI:       [            Block Device           ] 
> DMMP:       [   Path1         ][    Path2       ]  (Optional Layer)
> Disk:       [            LUN                    ] 
>  
> Do you see any problems (from the dm_crypt side) with this setup in terms of deadlocks, or unsupported stacking  or is this a "supposed to work" configuration ? 
> 
> I know that device mapper always causes performance penalty because of missing barrier support (earlier Kernels) and I/O splitting in 4k units, however I have a BBU, so not a problem really and performance penalty is allowed.
> 
> I have seen that the split to 4k causes latency to increase dramatically, however this seems to be a "minor" issue also (altought no solution so far).
> 
> Mit freundlichen Gr??en / Kind Regards
> Robert Heinzmann
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
> 

-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier 

  reply	other threads:[~2011-03-10 18:57 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-10 18:06 [dm-crypt] Question on Disk Layout (Stacking supported ?) Robert.Heinzmann
2011-03-10 18:57 ` Arno Wagner [this message]
2011-03-10 19:09 ` Milan Broz
2011-03-11  8:34   ` Robert.Heinzmann

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=20110310185738.GA3908@tansi.org \
    --to=arno@wagner.name \
    --cc=dm-crypt@saout.de \
    /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