Re: Plans to avoid weaknesses in big volumes?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

> 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.

> because it gives you the opportunity, to manage diskspace way
> better

I depend on large amounts of contiguous disk space.

> 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.


regards
   Mario
-- 
I've never been certain whether the moral of the Icarus story should
only be, as is generally accepted, "Don't try to fly too high," or
whether it might also be thought of as, "Forget the wax and feathers
and do a better job on the wings."            -- Stanley Kubrick


---------------------------------------------------------------------
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


[Index of Archives]     [Device Mapper Devel]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux