| 1 |
On 11/11/2015 07:19 PM, Neil Bothwick wrote: |
| 2 |
> On Wed, 11 Nov 2015 18:09:39 +0100, Ralf wrote: |
| 3 |
> |
| 4 |
>> Btrfs supports Raid10 but no block-crypto. |
| 5 |
>> |
| 6 |
>> If I would use a HD->MD Raid->Luks->Btrfs stack, I don't benefit from |
| 7 |
>> the Raid implementation of Btrfs. |
| 8 |
> Nor do you get the automatic repair of corruption that btrfs RAID offers. |
| 9 |
Oh cool, nice, I didn't know about that feature. But as you say, it's |
| 10 |
definitely better using btrfs's raid instead of using stacked md raid. |
| 11 |
> |
| 12 |
>> If I would use a HD->Luks->Btrfs stack, then I would have to use four |
| 13 |
>> different LUKS devices, which results in four individual encryptions |
| 14 |
>> (and I don't have AES-NI, so this would be a tremendous slowdown). |
| 15 |
> It would definitely be slower, but maybe not "tremendously". |
| 16 |
Well yes, I would say so. My Box doesn't have AES-NI instruction set and |
| 17 |
it 'only' has to relatively slow cores. |
| 18 |
4x independent Luks results in 4x independent (en|de)cryption. Even now, |
| 19 |
in my current configuration AES slows everything extremely down. |
| 20 |
(before setting up my disks a few years ago, i benchmarked the setup |
| 21 |
with and without luks. Afair, without Luks I had about Read:80Mib/s, |
| 22 |
with Luks it's about 50MiB/s, and yes, everything is aligned correctly) |
| 23 |
> |
| 24 |
>> What would be the best way to have a Raid 10 together with a encrypted |
| 25 |
>> Btrfs? |
| 26 |
> What about crypto on top of btrfs using a stacked filesystem like |
| 27 |
> ecryptfs? |
| 28 |
Nope, I also thought about that, but this is not elegant. Besides that, |
| 29 |
it would also slow down the system as ecryptfs runs in the VFS layer and |
| 30 |
is yet another layer which operates on top of an existing filesystem. |
| 31 |
(and not like luks, which would run a layer below btrfs). So that's a |
| 32 |
lot of overhead. |
| 33 |
|
| 34 |
Ecryptfs is really nice for encrypting dedicated files or directories |
| 35 |
but I don't think that it is a good solution for encrypting a _whole_ |
| 36 |
general purpose filesystem. |
| 37 |
|
| 38 |
And thinking about btrfs snapshot feature, using some 'btrfs history |
| 39 |
tool', i would probably only be able to see a lot of crypto garbage when |
| 40 |
going through my history (which can for sure be accessed by ecryptfs, |
| 41 |
but not by standard btrfs tools). |
| 42 |
|
| 43 |
Cheers |
| 44 |
Ralf |
Archives