From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from archlinux.org (gerolde.archlinux.org [66.211.214.132]) by mail.saout.de (Postfix) with ESMTP for ; Tue, 1 Jun 2010 17:00:22 +0200 (CEST) Message-ID: <4C052084.1030100@archlinux.org> Date: Tue, 01 Jun 2010 17:00:20 +0200 From: =?ISO-8859-15?Q?Thomas_B=E4chler?= MIME-Version: 1.0 References: In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigAE3F26CBFE5F7FEFA451E506" Subject: Re: [dm-crypt] dm-crypt alignment + ssd + raid List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Philippe Cerfon , dm-crypt This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigAE3F26CBFE5F7FEFA451E506 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Am 01.06.2010 16:34, schrieb Philippe Cerfon: > I have to scenarios: > A) Sofware RAID6, multiple partitions each to be encrypted. (Using the > kernel md for the software RAID) > B) Single SSD disk, multiple partitions each to be encrypted. >=20 >=20 > Regarding A: > 1) What is generally the best way to do this? I mean how to stack the > different levels of md/RAID, [LVM] (if used at all), dm-crypt. > I'd say one has about this: > (physical disk[s]) --> (MD/RAID6) --> (dm-crypt) --> ([LVM] if used at > all) --> filesystem >=20 > Or is another order "better"? > I think having MD/RAID at the bottom makes sense (instead of dm-crypt > at the bottom), at this should make recovery easier, right? > I'm not sure whether I need LVM at all, but I think it makes only > sense to have it on top of dm-crypt in order to use to use it to > enlarge volumes. > I guess one cannot enlarge a LUKS "filesystem", even if the an > unterlying LVM volume would be enlarged? I have used both scenarios in the past. The LUKS volume does not know its payload size, so it will use the maximum space available. In the scenario LVM->dm-crypt: Once you enlarge the underlying LV, you can either 'cryptsetup resize' or 'cryptsetup luksClose && cryptsetup luksOpen' for the volume to get the new size. The former does not even require unmounting the file system. The scenario dm-crypt->LVM is easier, as there is no extra layer between the LV and filesystem. Combined with a file system that can do online resizing (like ext3 on newer kernels, or ext4), you can enlarge the file system transparently, without any downtime. Shrinking is obviously more complicated. These days, I use LVM on top of dm-crypt. However, a LUKS volume encrypted with aes-xts-plain should not be bigger than 1TB for security reasons (I read that here, don't know the exact reason), so this might be unsuitable for your needs. > 2) I guess at any of the levels from above, one can partition the > exported block device, right? > So e.g. partition the physical disks that each has one big sdX1, and > create the RAID on it _OR_ create the RAID directly on the disk > withoug partitioning. I wouldn't rely on partitions, LVM is way more flexible. (Having /boot on LVM might not work and require a small partition, depending on the bootloader) Sorry, but I am not familiar with the alignment questions you posted, although I think with 2.6.33 and up-to-date userspace, all alignments should be correct automatically without any specific interaction from your end. Someone else will probably give a definitive answer on that. --------------enigAE3F26CBFE5F7FEFA451E506 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEAREIAAYFAkwFIIQACgkQEda5KzHP/VARAQCgrJLPHJqos35WBXMrQJCq3zEF 2k0AniqHP4qvFcnWFAKsFtC8p0jabKi+ =sBnw -----END PGP SIGNATURE----- --------------enigAE3F26CBFE5F7FEFA451E506--