Date: Fri, 27 Jul 2007 22:00:35 +0100 From: "Dominic Bishop" <dom@bishnet.net> To: <geom@FreeBSD.org> Subject: RE: Increasing GELI performance Message-ID: <20070727210032.0140413C457@mx1.freebsd.org> In-Reply-To: <46AA50B4.9080901@fluffles.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
> <device>. 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070727210032.0140413C457>