Date: Sat, 18 Aug 2007 07:20:26 -0500 From: Eric Anderson <anderson@freebsd.org> To: "N. Harrington" <drumslayer2@yahoo.com> Cc: freebsd-fs@freebsd.org, Pawel Jakub Dawidek <pjd@freebsd.org> Subject: Re: Gjournal reporting 1/2 the speed of non journaled? - examples Message-ID: <46C6E40A.2040300@freebsd.org> In-Reply-To: <249926.8148.qm@web34505.mail.mud.yahoo.com> References: <249926.8148.qm@web34505.mail.mud.yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
N. Harrington wrote: > --- Eric Anderson <anderson@freebsd.org> wrote: > >> N. Harrington wrote: >>> --- Pawel Jakub Dawidek <pjd@FreeBSD.org> wrote: >>> >>>> On Thu, Aug 16, 2007 at 06:02:09PM -0700, N. >>>> Harrington wrote: >>>>> With ZFS, I have not seen much new going on >> with >>>>> gjournal. I am curious what the status of >> gjournal >>>> and >>>>> if it will likely be included with 6.3 (whenever >>>> that >>>>> is due) >>>> That was the plan, but I'm not yet sure if I'll >> find >>>> time to do it. >>>> >>>>> Also, as of late, I have been using it with >>>>> 6.2-STABLE via the patches and I seem to be >>>> getting >>>>> 1/2 the transfer speeds compared to non >> journaled >>>>> disks. It seems like this is recent as previous >>>> tests >>>>> showed it as quite fast. >>>>> >>>>> Any suggestions on why this could be happening >>>>> greatly appreciated. >>>>> >>>>> tested via >>>>> dd if=/dev/zero of=./testfile bs=16 count=16384 >>>> Gjournal is ~two times faster than UFS+SU for >> many >>>> small, random and >>>> parallel writes (such as running few 'tar x' >>>> processes), but is two >>>> times slower than UFS+SU for one sequential write >>>> stream, as there is no >>>> much that can be optimized there. >>>> >>>>> With disks getting larger and larger, why is it >>>>> taking so long for a journaled filesystem to be >>>>> standard on BSD? >>>> We have ZFS now, we don't need journaled file >>>> system:) >>> >>> Here is an example of my tests and what I am >>> experiencing. >>> >>> FreeBSD server.old 6.2-PRERELEASE FreeBSD >>> 6.2-PRERELEASE #1: Wed Nov 22 21:20:08 PST 2006 >>> >>> With Gjournal: >>> root@:/1-journal> time dd if=/dev/zero >>> of=/1-journal/testfile1 bs=16k >>> count=16384 >>> 16384+0 records in >>> 16384+0 records out >>> 268435456 bytes transferred in 10.257279 secs >>> (26170240 bytes/sec) >>> dd if=/dev/zero of=/cache1/testfile1 bs=16k >>> count=16384 0.02s user 0.80s system 7% cpu 10.393 >>> total >>> >>> Without Gjournal: >>> root@1:/2-UFS> time dd if=/dev/zero >> of=/2/testfile1 >>> bs=16k >>> count=16384 >>> 16384+0 records in >>> 16384+0 records out >>> 268435456 bytes transferred in 26.682630 secs >>> (10060307 bytes/sec) >>> dd if=/dev/zero of=/home/testfile1 bs=16k >> count=16384 >>> 0.01s user 0.61s system 2% cpu 28.448 total >>> >>> As you can see, with this test, using Gjournaling >>> tested faster. >>> >>> Now on a new build: >>> >>> FreeBSD newtest 6.2-STABLE FreeBSD 6.2-STABLE #1: >> Tue >>> Aug 14 14:31:53 PDT 2007 >>> nicole@newtest:/usr/obj/spare/src/sys/GENERAL >> amd64 >>> Without Gjournal >>> root@newtest:/home/nicole> time dd if=/dev/zero >>> of=./testfile bs=16k count=16384 >>> 16384+0 records in >>> 16384+0 records out >>> 268435456 bytes transferred in 4.749401 secs >> (56519854 >>> bytes/sec) >>> dd if=/dev/zero of=./testfile bs=16k count=16384 >>> 0.01s user 0.45s system 9% cpu 4.751 total >>> >>> With Gjournaling: >>> root@newtest:/home/nicole> time dd if=/dev/zero >>> of=/tmp/testfile bs=16k >>> count=16384 >>> 16384+0 records in >>> 16384+0 records out >>> 268435456 bytes transferred in 7.505348 secs >> (35765891 >>> bytes/sec) >>> dd if=/dev/zero of=/tmp/testfile bs=16k >> count=16384 >>> 0.00s user 0.57s system 7% cpu 7.517 total >>> >>> So as shown here, my test on an older 6.2 (with >> same >>> patches) showed improved performance. But now on a >> new >>> 6.2 build system, shows decreased performance. >> Could it be that you are not writing quite enough >> data to fully test it? >> Maybe in the 'old' server case, you were stopping >> the write *just* >> before the journal switch happened, so you happened >> to see the best >> sequential write throughput. The other tests could >> happen to fall >> across a journal switch, which would increase the >> time for the test, >> probably dropping the throughput in half.. What do >> you think? >> >> >> Eric >> > Sadly I do not think my testing is in error. Since I > am comparing them equally and on very different > systems. They are also very repeatable. Thus I wonder > if some changes have occurred in 6.X within the past > months that have caused gjournal not not integrate > well. gjournal has not changed, since the patches have > been the same for some time. > > Also another post I had on questions was how, for me, > with 7.0 on a scsi system, it was reporting the disk > speed as 160Mb/s instead of 320Mb/s as it would on > 6.X. Speed tests show the same, but on bootup, the > speeds are not reported the same. Perhaps the result > of some of the changes being made on 7? > > If I get a chance, and figure out how, I will try to > scan the change log for 6.X for any changes in the > disk systems. I know of some changes that broke > Pawel's patches in 2 places awhile ago. But I know > even after those changes the speed was not effected. > The speed decline seems recent. Hmm.. Well, you could try the 'binary search' method, by cvs upping to a specific date, try it, and see if it exists, until you know that it happened in a certain range of time. Then finding the offending commit is *much* easier. If you narrow it down to a day or so, and post that, someone on this list can help you for sure. It's a time consuming task though... Eric
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?46C6E40A.2040300>