Encrypted zfs?
Pawel Jakub Dawidek
pjd at FreeBSD.org
Tue Aug 28 10:55:17 PDT 2007
On Tue, Aug 28, 2007 at 12:34:11PM +0100, Hugo Silva wrote:
> How's the performance on the geli-backed pool ?
It depends a lot on CPU speed, but you should be ready for visible
performance drop. I'll give you two examples:
1. 3 ATA/SATA disks in RAIDZ1 configuration:
CPU: Intel(R) Pentium(R) 4 CPU 3.00GHz (2992.70-MHz 686-class CPU)
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
ad1: 476940MB <Seagate ST3500630A 3.AAE> at ata0-slave UDMA100
ad4: 476940MB <Seagate ST3500630AS 3.AAK> at ata2-master SATA150
ad6: 476940MB <Seagate ST3500630AS 3.AAK> at ata3-master SATA150
Performance of sequential write/read without encryption:
# zpool status
pool: tank
state: ONLINE
scrub: none requested
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
raidz1 ONLINE 0 0 0
ad1 ONLINE 0 0 0
ad4 ONLINE 0 0 0
ad6 ONLINE 0 0 0
# dd if=/dev/zero of=/tank/zero bs=1m count=3000
96MB/s
# zpool export tank && zpool import tank
# dd if=/tank/zero of=/dev/null bs=1m
140MB/s
Performance of sequential write/read with encryption:
# zpool status
pool: tank
state: ONLINE
scrub: none requested
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
raidz1 ONLINE 0 0 0
ad1.eli ONLINE 0 0 0
ad4.eli ONLINE 0 0 0
ad6.eli ONLINE 0 0 0
# dd if=/dev/zero of=/tank/zero bs=1m count=3000
26MB/s
# zpool export tank && zpool import tank
# dd if=/tank/zero of=/dev/null bs=1m
38MB/s
In other words the impact in this example is significant. You need to
evaluate if you really need encryption. For my use it is totally
acceptable and I need encryption anyway.
2. 14 SCSI disks in RAIDZ2 configuration:
CPU: Intel(R) Xeon(R) CPU E5310 @ 1.60GHz (1597.65-MHz K8-class CPU)
FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs
14x
daX at isp0 bus 0 target 12 lun 0
daX: <HP 73.4G ST373405FC HP09> Fixed Direct Access SCSI-3 device
daX: 200.000MB/s transfers WWNN 0x20000004cf9b0c63 WWPN 0x22000004cf9b0c63 PortID 0xd2
daX: Command Queueing Enabled
daX: 70007MB (143374738 512 byte sectors: 255H 63S/T 8924C)
Unfortunately connected only through 2Gb FC.
Performance of sequential write/read without encryption:
# zpool status
pool: tank
state: ONLINE
scrub: none requested
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
raidz2 ONLINE 0 0 0
da0 ONLINE 0 0 0
da1 ONLINE 0 0 0
da3 ONLINE 0 0 0
da4 ONLINE 0 0 0
da5 ONLINE 0 0 0
da6 ONLINE 0 0 0
da7 ONLINE 0 0 0
da8 ONLINE 0 0 0
da9 ONLINE 0 0 0
da10 ONLINE 0 0 0
da11 ONLINE 0 0 0
da12 ONLINE 0 0 0
da13 ONLINE 0 0 0
da14 ONLINE 0 0 0
# dd if=/dev/zero of=/tank/zero bs=1m count=3000
103MB/s
# zpool export tank && zpool import tank
# dd if=/tank/zero of=/dev/null bs=1m
125MB/s
Performance of sequential write/read with encryption:
# zpool status
pool: tank
state: ONLINE
scrub: none requested
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
raidz2 ONLINE 0 0 0
da0.eli ONLINE 0 0 0
da1.eli ONLINE 0 0 0
da3.eli ONLINE 0 0 0
da4.eli ONLINE 0 0 0
da5.eli ONLINE 0 0 0
da6.eli ONLINE 0 0 0
da7.eli ONLINE 0 0 0
da8.eli ONLINE 0 0 0
da9.eli ONLINE 0 0 0
da10.eli ONLINE 0 0 0
da11.eli ONLINE 0 0 0
da12.eli ONLINE 0 0 0
da13.eli ONLINE 0 0 0
da14.eli ONLINE 0 0 0
# dd if=/dev/zero of=/tank/zero bs=1m count=3000
91MB/s
# zpool export tank && zpool import tank
# dd if=/tank/zero of=/dev/null bs=1m
122MB/s
The negative impact on performance is much smaller here.
I'm quite sure impact is much less for random, parallel access.
Sequential operations (write not as much as reads in ZFS case) are
sensitive on higher latency.
But don't you worry, when you must have encryption, you don't really
care about performance. And when you decided not to use encryption,
because it introduces too big overhead, it only means that you didn't
need encryption in the first place:)
--
Pawel Jakub Dawidek http://www.wheel.pl
pjd at FreeBSD.org http://www.FreeBSD.org
FreeBSD committer Am I Evil? Yes, I Am!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20070828/f050ffd9/attachment.pgp
More information about the freebsd-current
mailing list