Gjournal reporting 1/2 the speed of non journaled? - examples

[Eric Anderson]

N. Harrington wrote:
> --- Eric Anderson <anderson at freebsd.org> wrote:
> 
>> N. Harrington wrote:
>>> --- Pawel Jakub Dawidek <pjd at 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 at 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 at newtest:/usr/obj/spare/src/sys/GENERAL 
>> amd64
>>> Without Gjournal
>>> root at 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 at 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