Mario 'BitKoenig' Holbe schrieb:
Sven Eschenberg <sven@xxxxxxxxxxxxxxxxxxxxx> wrote:
For Softwareraid/Fake-HW-RAID, you can encrypt the single physical
volumes, and construct the aray out of those, you could even slice them
Assembling RAIDs from crypted volumes is horribly CPU-bound since you
have to crypt the same data (and/or it's parity) multiple times.
Agreed, as I said, it would be one option, on the other hand, encryption
and speed are a contradiction in it's very nature.
Even small RAID Arrays can easily yield 500MB/sec and more in matters of
IO bandwidth. Which means, that even a top notch quad core couldn't keep
up with that IO bandwidth, not talking about scenarios, where the CPU is
actually needed for processing/computation.
For RAID arrays HW crypto devices are the only feasable option, I guess.
(a 3GHz dualcore using both cores can achieve roughly 200MB/sec as
encryption bandwidth for something like XTS, so the values are 'rough'
estimates.)
Controller. Usually HW Controllers can create a bunch of volumes ontop of
a single array, the corrssponding tool would be lvm2 (though lvm2 might be
more flexible than what HW controllers offer).
Usually you would want to contruct a series of logical volumes in this
manner,
Well, personally I'm not able to postulate "usual" usage-patterns but I
know very well that I myself do not want to construct series of logical
volumes and I'm not even able to do so, since my data is not logically
distributable over different filesystems in a way that would make any
sense.
Okay, of course there are various posibilities, let me refine this: In
many server scenarios, you would want to have the flexibility, to move
space between filesystems/encrypted and unencrypted areas.
because it gives you the opportunity, to manage diskspace way
better
I depend on large amounts of contiguous disk space.
Then I guss LVM is your only option anyway. Adding too many disks in a
single array increases the possibility of a failure, thus you'D want to
limit the number of disks per array. If your filesystem exceeds the size
of a single array, you'd need to use LVM to span one logical volume over
several arrays anyway.
you can select if chunks are encrypted and in what way. You'd then
pull those encrypted volumes together with lvm again in any way you please
(I don't see any prticular reason, why stacking lvms should be bad, I'd
Currently I completely avoid lvm (because I just have no need for it)
and keep my stacks small.
Surely I could somehow stack virtual block-devices over virtual
block-devices over virtual block-devices over ... you name it. But I
don't think this makes things better, more efficient, less error prone
or more robust at all.
That's true. Then again, both (softraid and lvm) are both only DM
targets and a tighter integration of their metadataformats would be very
reasonabe, esp. if you think about the fact, that lvm already offers
striping/mirroring.
BTW: Aren't partitions just virtual block devices too?
regards
Mario
I can see your point, then again, if we already have a metadata format,
why not use it. cryptsetup could of course autocreate 'chunks' and
describe them in the lvm metadata format, this gives cryptsetup the
possibility to store a header alongside each chunk.
And yes, I'd certainly welcome a stronger integration of the softraid
setup tools, lvm2 and cryptsetup, because aside from different metadata
formats they all do a very similiar job.
Regards
-Sven
---------------------------------------------------------------------
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
