Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 20 Apr 2008 17:14:58 +0200 (CEST)
From:      Wojciech Puchar <wojtek@wojtek.tensor.gdynia.pl>
To:        hideo <hideo@lastamericanempire.com>
Cc:        freebsd-questions@freebsd.org
Subject:   Re: gmirror, geli, gjournal performance
Message-ID:  <20080420170922.W1173@wojtek.tensor.gdynia.pl>
In-Reply-To: <20080419172100.GA3638@lastamericanempire.com>
References:  <20080419172100.GA3638@lastamericanempire.com>

next in thread | previous in thread | raw e-mail | index | archive | help
>
> I was replacing a disk in a gmirror+geli pair and decided to compare
> the performance of gmirror+geli+gjournal before adding the new disk.


too much mixer in one to give exact answer.


gmirror - no slowdown, faster reads when at least 2 concurrent, near 0 CPU 
load
geli - high CPU load, performance depends mostly on CPU
gjournal - extra overhead on writes, no difference on reads.

> When using these three together is the appropriate order to 1) fdisk
> and label 2) mirror the disk, 3) geli the partitions, and 4) use the
> geli partitions for gjournal label?

right.

> With respect to performance, I find the writes to the gjournal disk
> about half as fast, which I expected from the benchmarks I've seen.

which - with geli, means twice CPU load.

do you really need gjournal.

> However, reading a single file is identical between the two:
>
>        dd if=/sofupdates/1.mpg of=/dev/null bs=1m
>        994049168 bytes transferred in 34.858793 secs (28516454 bytes/sec)
>
>        dd if=/gjournal/1.mpg of=/dev/null bs=1m
>        994049168 bytes transferred in 34.335267 secs (28951258 bytes/sec)
>
> Is this expected? I was under the impression that reads should be
> somewhat faster with gjournal.

wrong impression. reads are the same.

it's best to make sure your hardware and kernel config are OK and system 
doesn't crash every day, and don't use gjournal.

fsck isn't that long, is used only after crash, it's not worth extra 
overhead under NORMAL operation.

with geli - divide your system to partitions the way that not secret data 
are not geli encrypted.

for sure your /usr may be unencrypted, just move /usr/local/etc to 
somewhere out of /usr


geli is very good but needs lots of CPU power.

on my core 2 duo system i was able to get total of 100MB/s (concurrent 
from many disks) with geli, at that point both cores was fully used.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080420170922.W1173>