Re: Journaling UFS with gjournal.

On Tue, 20 Jun 2006, Ulrich Spoerlein wrote:

> Pawel Jakub Dawidek wrote:
>> Hello.
>>
>> For the last few months I have been working on gjournal project.
>
> Cool Stuff!
>
>> Reading. grep -r on two src/ directories in parallel:
>> UFS:		84s
>> UFS+SU:		138s
>> gjournal(1):	102s
>> gjournal(2):	89s
>>
>> As you can see, even on one disk, untaring eight src.tgz is two times
>> faster than UFS+SU. I've no idea why gjournal is faster in reading.
>
> The UFS+SU score doesn't seem right. Why do SU have a negative impact on
> read performance? Is it solely because of the atime updates?

ffs+SU is only 1-10% slower than ffs in my benchmarks of reading back
a copy of most of src/ written to a new file system by the same
filesystem (code) that does the readback.  The speed only depends on
which file system wrote the data.  I use tar for reading.  Maybe
concurrent greps on separate directories amplify the problem.

A tiny subset of saved benchmarked output:
%%%
Jan 29  2004
real-current writing to WD 1200JB h: 26683965 73593765
---
srcs = "contrib crypto lib sys" in /usr/src
ffs-16384-02048-1:
tarcp /f srcs:                 43.23 real         0.65 user         6.85 sys
tar cf /dev/zero srcs:         15.58 real         0.19 user         2.13 sys
ffs-16384-02048-2:
tarcp /f srcs:                 41.26 real         0.50 user         7.06 sys
tar cf /dev/zero srcs:         15.80 real         0.25 user         2.10 sys
ffs-16384-02048-as-1:
tarcp /f srcs:                 22.17 real         0.49 user         6.47 sys
tar cf /dev/zero srcs:         15.52 real         0.22 user         2.13 sys
ffs-16384-02048-as-2:
tarcp /f srcs:                 21.67 real         0.45 user         6.61 sys
tar cf /dev/zero srcs:         15.65 real         0.19 user         2.16 sys
ffs-16384-02048-su-1:
tarcp /f srcs:                 60.35 real         0.49 user         7.02 sys
tar cf /dev/zero srcs:         17.32 real         0.20 user         2.15 sys
ffs-16384-02048-su-2:
tarcp /f srcs:                 61.82 real         0.50 user         7.14 sys
tar cf /dev/zero srcs:         17.56 real         0.21 user         2.17 sys
%%%

Notation: 16384-02048 is the block-frag size;
/""/as/su/ are /default/async mounts/soft updates/; -[12] is ffs[12].
The source tree is prefetched into VMIO so that the copy part of the
benchmark is mostly a write benchmark and is not affected by any slowness
in the physical source file system.

The above shows soft updates being about 2 seconds or 10% slower for
read-back.  It also shows that soft updates is about 3 times as slow
as async mounts and about 1.5 times as slow as the default (sync
metadata and async data).  Soft updates was faster than the default
when it was first implemented, but became slower at least for writing
a copy of src/.  This seems to be due to soft updates interacting
badly with bufdaemon.  This may be fixed now (I have later runs of the
benchmark showing soft updates having about the same speed as the
default, but none for -realcurrent).

I never found the exact cause of the slower readback.  My theory is
that block allocation is more delayed in the soft updates case, and
soft updates uses this to perfectly pessimize some aspects of the
allocation.  My version of ffs allocates the first indirect block
between the NDADDR-1'th and NDADDR'th data blocks.  This seems to
help generally, and reduces the disadvantage of soft updates.  IIRC,
the default normally puts this block not very far away but not
necessarily between the data blocks, but soft updates pessimizes it
by moving it a long way away.  It's still surprising that this makes
nearly a 10% difference for src/, since most files in src/ are too
small to have even 1 indirect block.

I always disable atime updates on ffs file systems and don't have
comparitive benchmarks for the difference from this.

Bruce