From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by mail.saout.de (Postfix) with ESMTP for ; Thu, 10 Mar 2011 20:09:18 +0100 (CET) Message-ID: <4D7921D4.9080907@redhat.com> Date: Thu, 10 Mar 2011 20:09:08 +0100 From: Milan Broz MIME-Version: 1.0 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dm-crypt] Question on Disk Layout (Stacking supported ?) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Robert.Heinzmann@deutschepost.de Cc: dm-crypt@saout.de 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 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