From owner-freebsd-current@FreeBSD.ORG Tue Aug 28 17:55:17 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 666ED16A41A for ; Tue, 28 Aug 2007 17:55:17 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.freebsd.org (Postfix) with ESMTP id 9A75313C428 for ; Tue, 28 Aug 2007 17:55:14 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id C6B0C4569A; Tue, 28 Aug 2007 19:55:12 +0200 (CEST) Received: from localhost (154.81.datacomsa.pl [195.34.81.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id C9DFF45683; Tue, 28 Aug 2007 19:55:07 +0200 (CEST) Date: Tue, 28 Aug 2007 19:54:02 +0200 From: Pawel Jakub Dawidek To: Hugo Silva Message-ID: <20070828175402.GB39562@garage.freebsd.pl> References: <46D2C812.8090106@gmail.com> <20070828104625.GB36596@garage.freebsd.pl> <46D40833.2030007@barafranca.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XOIedfhf+7KOe/yw" Content-Disposition: inline In-Reply-To: <46D40833.2030007@barafranca.com> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-2.6 required=3.0 tests=BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-current@FreeBSD.ORG Subject: Re: Encrypted zfs? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2007 17:55:17 -0000 --XOIedfhf+7KOe/yw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 at ata0-slave UDMA100 ad4: 476940MB at ata2-master SATA150 ad6: 476940MB 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=3D/dev/zero of=3D/tank/zero bs=3D1m count=3D3000 96MB/s # zpool export tank && zpool import tank # dd if=3D/tank/zero of=3D/dev/null bs=3D1m 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=3D/dev/zero of=3D/tank/zero bs=3D1m count=3D3000 26MB/s # zpool export tank && zpool import tank # dd if=3D/tank/zero of=3D/dev/null bs=3D1m 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: Fixed Direct Access SCSI-3 device=20 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=3D/dev/zero of=3D/tank/zero bs=3D1m count=3D3000 103MB/s # zpool export tank && zpool import tank # dd if=3D/tank/zero of=3D/dev/null bs=3D1m 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=3D/dev/zero of=3D/tank/zero bs=3D1m count=3D3000 91MB/s # zpool export tank && zpool import tank # dd if=3D/tank/zero of=3D/dev/null bs=3D1m 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:) --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --XOIedfhf+7KOe/yw Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFG1GE5ForvXbEpPzQRAhpMAKCUCC/Jlwea0/VcBI1shX3eTUOgkwCfcl+r NHEtNDe8jmrZE8lLpJn6X3c= =RZIV -----END PGP SIGNATURE----- --XOIedfhf+7KOe/yw--