Hi! I have it the other way round so far: I built a RAID, onto this I put LVM with a few partitions. Currently I use luks only on one of those partitions, I run an encrypted swap. So far, I have not experienced problems. I will run another few tests like growing the RAID, expanding the logical volume, move data from one physical volume to another (and remove the old one) and will check how well my cswap reacts to it. If everything survives, then I will be confident enough to move my /home, which currently resides on a separate raid without lvm, to a freshly created logical volume. So far, raid expansion and filesystem expansion has worked absolutely flawlessly for me! I did it a few times, once with the filesystem umount-ed, once mounted, all went well. regards, sulla Clayton Shepard wrote: > I would like to note that you have a couple options on where you put the > LUKS. On my setup I did it after the raid but before the LVM if I recall > correctly. Unfortunately this only allows one dmcrypt process to run, which > ends up being a huge bottleneck for any relatively new raid array (my > throughput dropped from 500MB/s to 80MB/s). If you put LUKS on each drive > individually before setting up mdadm, then you have N dmcrypt processes > which could potentially give you much better performance if you have an SMP > system. Unfortunately this also means you would have to enter your password > N times, but a script to do it automatically shouldn't be too hard to write, > although there may be some security considerations there... > > Regards, > > -Clay > > On Thu, Feb 5, 2009 at 2:01 AM, Ryan Castellucci <ryan.castellucci@xxxxxxxxx >> wrote: > >> On Mon, Nov 10, 2008 at 3:45 PM, Wolfgang Sailer >> <Wolfgang@xxxxxxxxxxxxxx> wrote: >>> Dear all! >>> >>> I have a question regarding luks on lvm: >>> >>> Currently I am running LUKS on a 6-disk raid 5, where every disk has 1 >>> primary partition that takes part in the raid. So far no problems. But >> I'm >>> running out of space. >>> >>> So I would like to buy 2 new drives, set them up as a raid 1 (for >>> convenience i would add the whole drives to the raid without creating >>> partitions on them), add the raid as (the only) volume to a lvm volume >> group >>> and put several partitions on the lvm: unencrypted ones for root, home >> ... >>> and one encrypted to hold critical data. Then I intend to copy over the >> data >>> from the 6 disk encrypted raid5 to the new drives' encrypted logical >>> partition and dismantle the 6 drives. >>> >>> I think such a setup is perfectly valid, but is there any concern putting >>> luks on a virtual partition in a volume group consisting of a raid1? Do I >>> need to take something special into account, like setting up lvm in a >>> special way (certain block size...) to make it work smoothly with luks? >> Do I >>> need to tell luks some additional information such that it is installed >> on >>> lvm? Is such a setup as stable as putting luks on real partitions? >>> >>> Should I fill the whole disk with /dev/urandom or just the partition that >>> will hold the luks volume? >>> >>> What if I add another disk (or raid volume) to the volume group in order >> to >>> expand the space in future? Will that disturb luks? I have done a smooth >>> raid5 expansion from 4 to 5 to 6 disks in the past followed by a luks >>> expansion and an ext3 expansion, but never an lvm expansion... >> I've been running LUKS on LVM2 on RAID6 for almost two years. It's >> been unfazed by disk failure, lvresizes, hard power offs, etc. The >> defaults work fine for me, though they may be sub-optimal.. I've used >> both XFS and ext3 without problems. >> >> -- >> Ryan Castellucci http://ryanc.org/ >> >> --------------------------------------------------------------------- >> dm-crypt mailing list - http://www.saout.de/misc/dm-crypt/ >> To unsubscribe, e-mail: dm-crypt-unsubscribe@xxxxxxxx >> For additional commands, e-mail: dm-crypt-help@xxxxxxxx >> >> > --------------------------------------------------------------------- dm-crypt mailing list - http://www.saout.de/misc/dm-crypt/ To unsubscribe, e-mail: dm-crypt-unsubscribe@xxxxxxxx For additional commands, e-mail: dm-crypt-help@xxxxxxxx
