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 _at_ 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!
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:16 UTC