Date: Thu, 22 Jun 2006 01:30:18 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Ulrich Spoerlein <uspoerlein@gmail.com> Cc: freebsd-fs@FreeBSD.org, freebsd-current@FreeBSD.org, Pawel Jakub Dawidek <pjd@FreeBSD.org>, freebsd-geom@FreeBSD.org Subject: Re: Journaling UFS with gjournal. Message-ID: <20060622003036.M52310@delplex.bde.org> In-Reply-To: <20060620173339.GA1638@roadrunner.informatik.uni-wuerzburg.de> References: <20060619131101.GD1130@garage.freebsd.pl> <20060620173339.GA1638@roadrunner.informatik.uni-wuerzburg.de>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060622003036.M52310>