From owner-freebsd-fs@FreeBSD.ORG Sat Aug 18 12:20:33 2007 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6F4F916A419; Sat, 18 Aug 2007 12:20:33 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from ns.trinitel.com (186.161.36.72.static.reverse.ltdomains.com [72.36.161.186]) by mx1.freebsd.org (Postfix) with ESMTP id 39A5313C459; Sat, 18 Aug 2007 12:20:33 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from proton.local (r74-193-81-203.pfvlcmta01.grtntx.tl.dh.suddenlink.net [74.193.81.203]) (authenticated bits=0) by ns.trinitel.com (8.14.1/8.14.1) with ESMTP id l7ICKTTE058505; Sat, 18 Aug 2007 07:20:32 -0500 (CDT) (envelope-from anderson@freebsd.org) Message-ID: <46C6E40A.2040300@freebsd.org> Date: Sat, 18 Aug 2007 07:20:26 -0500 From: Eric Anderson User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: "N. Harrington" References: <249926.8148.qm@web34505.mail.mud.yahoo.com> In-Reply-To: <249926.8148.qm@web34505.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on ns.trinitel.com Cc: freebsd-fs@freebsd.org, Pawel Jakub Dawidek Subject: Re: Gjournal reporting 1/2 the speed of non journaled? - examples X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Aug 2007 12:20:33 -0000 N. Harrington wrote: > --- Eric Anderson wrote: > >> N. Harrington wrote: >>> --- Pawel Jakub Dawidek 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