[dm-crypt] Question on Disk Layout (Stacking supported ?)

[dm-crypt] Question on Disk Layout (Stacking supported ?)

[Robert.Heinzmann]

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

Re: [dm-crypt] Question on Disk Layout (Stacking supported ?)

[Arno Wagner]

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 

Re: [dm-crypt] Question on Disk Layout (Stacking supported ?)

[Milan Broz]

On 03/10/2011 07:06 PM, Robert.Heinzmann@deutschepost.de wrote:

> 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 ?

Stacking should work without problems. Just when online resizing
you need additional step when resizing crypt device
(cryptsetup resize <dev> is for online resize. Or just activate/
deactivate and it loads new size.)

I depends on your preference if you want use LVM over LUKS or vice versa,
both works.

Basically stacking is design feature of device-mapper.

> 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.

Barrier (or flush) is fully supported in recent kernels, even for dmcrypt.
Split to 4k unit is also solved long time ago, dmcrypt provides
io merge functionality so even when stacking devices it uses
"ideal" io size - depends on underlying device and io pattern.

So it depends on which distro and kernel you are using.
(I guess you are using RHEL5 clone, even there it can be configure
efficiently. In fact many users have very similar configuration like you
described.)

Milan

Re: [dm-crypt] Question on Disk Layout (Stacking supported ?)

[Robert.Heinzmann]

Hello Milan, 

> Stacking should work without problems. Just when online 
> resizing you need additional step when resizing crypt device 
> (cryptsetup resize <dev> is for online resize. Or just 
> activate/ deactivate and it loads new size.)

thanks for the feedback. I guess this is the way to go then. I found
this setup very usefull. It allows for auto-resizing and providing one
machine image for multiple use cases (which is good for "the clouds").

And you are right that RedHat EL is the main focus (RHEL 5.4), so the
feedback is very valuable.

> So it depends on which distro and kernel you are using.
> (I guess you are using RHEL5 clone, even there it can be 
> configure efficiently. In fact many users have very similar 
> configuration like you
> described.)

Do you have some hint regarding this for "best practice" setups ? (RHEl
Docs ?)

While this is more of a "general storage" issue, do you mean tuning the
scheuler / readahead or tuning dm_crypt ?

Regards, 
Robert