On Fri, 24 Apr 2015 02:00:49 PM Noah O'Donoghue wrote:
On 24 April 2015 at 12:54, Toby Corkindale <toby@dryft.net> wrote:
I think people were suggesting blanking each removed half of the array, prior to making the underlying block device encrypted, then adding and re-mirroring.
Wait, you're suggesting encrypting each drive separately, and then adding the result to a linux RAID device?
That's.... crazy, but it might even work.
It will work.
Would be interesting to see what happens to performance considering you have to do a different encryption operation per drive of the RAID array.
For as long as LUKS has been available commonly available CPUs have been able to encrypt/decrypt significantly faster than disks can write/read. CPUs have been increasing in speed at a greater rate than disks, so I really don't think a pair of separately encrypted disks is going to take much CPU time. If you had a pair of SSDs then bulk IO wouldn't be a problem as the commonly available SSDs aren't THAT fast for bulk IO. But if you had lots of random seeks then the latency of encryption might slow things down a bit, but it would probably only be noticable in benchmark results not in real world operations.
Unfortunately it looks like it's impossible to convert an existing single drive to a RAID drive.. Or at least the instructions here do the good old copy from one to the other dance.
https://wiki.archlinux.org/index.php/Convert_a_single_drive_system_to_RAID
I suppose you could in theory do this for systems that are already RAID 1 though.. (as Russell suggests)
You can convert a BTRFS filesystem from a single disk to RAID-1 while it's running. But upgrading to BTRFS is another step that involves downtime. I think that the best thing to do is have some scheduled down-time to convert the system to RAID-1 with encryption. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/