gmirror, geli, gjournal performance
wojtek at wojtek.tensor.gdynia.pl
Mon Apr 21 12:09:24 UTC 2008
> 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
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?
> 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.
More information about the freebsd-questions