From owner-freebsd-geom@FreeBSD.ORG Fri Jul 27 21:00:32 2007 Return-Path: Delivered-To: geom@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7BB8516A418 for ; Fri, 27 Jul 2007 21:00:32 +0000 (UTC) (envelope-from dom@bishnet.net) Received: from carrick.bishnet.net (unknown [IPv6:2001:618:400::54ea:1138]) by mx1.freebsd.org (Postfix) with ESMTP id 0140413C457 for ; Fri, 27 Jul 2007 21:00:32 +0000 (UTC) (envelope-from dom@bishnet.net) Received: from cpc1-warw1-0-0-cust384.sol2.cable.ntl.com ([86.20.169.129] helo=magellan.dom.bishnet.net ident=mailnull) by carrick.bishnet.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.66 (FreeBSD)) (envelope-from ) id 1IEWv9-000H9K-Ve for geom@FreeBSD.org; Fri, 27 Jul 2007 22:00:24 +0100 Received: from deimos.dom.bishnet.net ([192.168.3.100] helo=deimos) by magellan.dom.bishnet.net with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IEWv9-000NKy-MJ for geom@FreeBSD.org; Fri, 27 Jul 2007 22:00:23 +0100 From: "Dominic Bishop" To: Date: Fri, 27 Jul 2007 22:00:35 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfQieXtn3Z6gHUFR1uBrUNF7dA5kgABmfIQ In-Reply-To: <46AA50B4.9080901@fluffles.net> X-Bishnet-MailScanner-Information: Contact postmaster@bishnet.net X-Bishnet-MailScanner-VirusCheck: Found to be clean X-Bishnet-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-0.693, required 5, autolearn=not spam, AWL 1.77, BAYES_00 -2.60, FORGED_RCVD_HELO 0.14, SPF_PASS -0.00) X-Bishnet-MailScanner-From: dom@bishnet.net Message-Id: <20070727210032.0140413C457@mx1.freebsd.org> Cc: Subject: RE: Increasing GELI performance X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2007 21:00:32 -0000 > Fluffles wrote: > > Dominic Bishop wrote: > > Another problem I've found is that if I use a sector size > for GELI > > > 8192 bytes then I'm unable to newfs the encrypted partition > > afterwards, it fails immediately with this error: > > > > newfs /dev/da0p1.eli > > increasing block size from 16384 to fragment size (65536) > > /dev/da0p1.eli: 62499.9MB (127999872 sectors) block size 65536, > > fragment size 65536 > > using 5 cylinder groups of 14514.56MB, 232233 blks, > 58112 inodes. > > newfs: can't read old UFS1 superblock: read error from > block device: > > Invalid argument > > > > The underlying device is readable/writeable however as dd can > > read/write to it without any errors. > > > > Newfs will use 512-byte sectors by default so if you're using > an 8KB sector size you need: > > newfs -S 8192 /dev/da0p1.eli > > To view the sector size you can also use diskinfo -v > . You can never write or read below the sector size > (thats right, not even the filesystem can do that!) > > I can't help you with your GELI question. I'm assuming you > run a quadcore 1.6GHz Xeon CPU? It should give you more > performance than 50MB/s especially with 4 threads. On my > Athlon 64 X2 3800+ (2x 2.0GHz > 512KB) i got around 100 i believe. Do know that AMD > processors perform relatively better in AES than Intel's line > of CPUs, but with a quadcore i would have expected at least > 160MB/s of thoughput. Maybe you should try geli on the raw > device? Like: > > geli onetime da0 > dd if=/dev/da0.eli of=/dev/null bs=1m count=1000 dd > if=/dev/zero of=/dev/da0.eli bs=1m count=1000 > > It goes without saying that you should unmount and make sure > no geom layer is using the da0 device. > > Good luck! > > - Veronica > The -S option didn't help, I tried using -S 65536 on a geli partition created with -s 65536 and got exactly the same error. newfs -S 65536 /dev/da0p1.eli increasing block size from 16384 to fragment size (65536) /dev/da0p1.eli: 62499.9MB (127999872 sectors) block size 65536, fragment size 65536 using 5 cylinder groups of 14514.56MB, 232233 blks, 58112 inodes. newfs: can't read old UFS1 superblock: read error from block device: Invalid argument It seems to be completely ignoring it and going with 512 byte sectors anyway, judging from the size versus number of sectors listed. I just tried your suggestion of geli on the raw device and it is no better at all: dd if=/dev/da0.eli of=/dev/null bs=1m count=1000 1000+0 records in 1000+0 records out 1048576000 bytes transferred in 29.739186 secs (35259069 bytes/sec) dd if=/dev/zero of=/dev/da0.eli bs=1m count=1000 1000+0 records in 1000+0 records out 1048576000 bytes transferred in 23.501061 secs (44618241 bytes/sec) Using top -S with 1s refresh to list the geli processes whilst doing this it seems only one of them is doing anything at any given time, the others are sitting in a state of "geli:w", I assume that is a truncation of something, maybe geli:wait at a guess. For comparison, here are the same tests done on the unencrypted raw device: dd if=/dev/da0 of=/dev/null bs=1m count=1000 1000+0 records in 1000+0 records out 1048576000 bytes transferred in 5.802704 secs (180704717 bytes/sec) dd if=/dev/zero of=/dev/da0 bs=1m count=1000 1000+0 records in 1000+0 records out 1048576000 bytes transferred in 4.026869 secs (260394859 bytes/sec) Dominic.