The problem that I initially ran into when I was creating the volume was that there wasn't a Linux file system that could handle a 27 TB volume. The closest that I got was Btrfs and the time, it was still in I think 0.98alpha or something like that.
Also as a result of that, there were no data recovery tools available that in the event of a RAID failure (but the drives are otherwise intact) that I need to be able to do a data recovery off the drives and to be able to pull the data and stitch it back together. Now the plan is for the clone/mirrored server (that also has plans for LTO tape expansion) that the data going on the tapes will be the fully encrypted files. If I do the volume encryption, the decryption will be also tied to the volume; which limits possiblities (if I understand it correctly) in porting the data forward as the volume or volumes grow. Conversely, if I encrypt the files (rather than the volume); then the encryption isn't linked to the volume itself; which means it can be next-gen-ext4, ZFS, btrfs (when it matures) etc... And even if I were to encrypt the entire volume; the question of whether AES-NI is enabled or disabled by default will still be persistent. (There are also early analysis plans that are currently being studied to implement 4x QDR Infiniband and all network traffic will be pushed onto that NIC/protocol instead, resulting in a net 32 Gbps connection per port.) So there are some high level planning stuff that's going on - but I'm currently studying the encryption aspect of it (out of the whole grand scheme/big picture of things). (There's SOME reasoning to the madness...) On Wed, Mar 13, 2013 at 4:04 PM, Matthew Hall <mh...@mhcomputing.net> wrote: > On Wed, Mar 13, 2013 at 04:00:48PM -0400, Ewen Chan wrote: >> I'm running on a 30 TB server with about 1.4 million files. >> >> I think that at last audit, the single largest file is 45 GB (as an example). >> >> And I'm prepping to run AES-256-CBC. >> >> The host system has a SATA 6 Gbps, 10 drive, RAID5 array; so I'm >> pretty sure that I can peg (or at least supply) the full 6 Gbps >> bandwidth for encryption. >> >> I'm currently using OpenSSL 0.9.8, and evaluations to upgrade to the >> latest openssl package is also being considered at this time (as well >> as possible a change to the host system OS to Linux (e.g. Ubuntu >> 12.04) or Solaris 11) or that I am just going to stream the data over >> 10 GbE connection (by mounting over SMB/NFS and running the encryption >> using the client processor, but the data is just being passed through >> during the encryption process - no data is stored on the client system >> post-encryption). >> >> The openssl wasn't recompiled from source; but whatever's >> built/included with the OS. > > Why not use the latest Linux kernel full disk and/or partition encryption via > dmraid or other technique, which has AES-NI support in-kernel, to avoid > userspace overhead which will be considerable with such throughput goals? > > Matthew. > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List openssl-users@openssl.org > Automated List Manager majord...@openssl.org ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
