On 6/27/2011 9:55 AM, Roberto Waltman wrote:
I recently bought an HP Proliant Microserver for a home file server.
( pics and more here:
http://arstechnica.com/civis/viewtopic.php?p=20968192 )
I installed 5 1.5TB (5900 RPM) drives, upgraded the memory to 8GB, and
installed Solaris 11 Express without a hitch.
A few simple tests using "dd" with 1gb and 2gb files showed excellent
transfer rates: ~200 MB/sec on a 5 drive raidz2 pool, ~310 MB/sec on a
five drive pool with no redundancy.
That is, until I enabled encryption, which brought the transfer rates
down to around 20 MB/sec...
Obviously the CPU is the bottleneck here, and I?m wondering what to do
next.
I can split the storage into file systems with and without encryption
and allocate data accordingly. No need, for example, to encrypt open
source code, or music. But I would like to have everything encrypted
by default.
My concern is not industrial espionage from a hacker in Belarus, but
having a disk fail and send it for repair with my credit card
statements easily readable on it, etc.
I am new to (open or closed)Solaris. I found there is something called
the Encryption Framework, and that there is hardware support for
encryption.
This server has two unused PCI-e slots, so I thought a card could be
the solution, but the few I found seem to be geared to protect SSH and
VPN connections, etc., not the file system.
Cost is a factor also. I could build a similar server with a much
faster processor for a few hundred dollars more, so a $1000 dollar
card for a < $1000 file server is not a reasonable option.
Is there anything out there I could use?
Thanks,
Roberto Waltman
You're out of luck. The hardware-encryption device is seen as a small
market by the vendors, and they price accordingly. All the solutions are
FIPS-compliant, which makes them non-trivially expensive to
build/test/verify.
I have yet to see the "basic" crypto accelerator - which should be as
simple as an FPGA with downloadable (and updateable) firmware.
The other major cost point is the crypto plugins - sadly, there is no
way to simply have the CPU farm off crypto jobs to a co-processor. That
is, there's no way for the CPU to go "oh, that looks like I'm running a
crypto algorithm - I should hand it over to the crypto co-processor".
Instead, you have to write custom plugin/drivers/libraries for each OS,
and pray that each OS has some standardized crypto framework. Otherwise,
you have to link apps with custom libraries.
I'm always kind of surprised that there hasn't been a movement to create
standardized crypto commands, like the various FP-specific commands that
are part of MMX/SSE/etc. That way, most of this could be done in
hardware seamlessly.
--
Erik Trimble
Java System Support
Mailstop: usca22-123
Phone: x17195
Santa Clara, CA
Timezone: US/Pacific (GMT-0800)
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
