Gjournal reporting 1/2 the speed of non journaled? What is the status of Gjournal?

[Eric Anderson]

N. Harrington wrote:
> --- Eric Anderson <anderson at freebsd.org> wrote:
> 
>> On 08/16/07 20:02, 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)
>>>
>>>  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.
>> It would help if you included your gjournal
>> configuration, file system 
>> configuration (how it was newfs'ed), what kind of
>> performance you saw, 
>> and what you expected.
> 
>  I left it "vague" as I was trying it on 3 different
> setups. Also, since whatever the speed was with UFS,
> became 1/2 with journal. So were I started from, each
> being different, does not matter or really help.
> 
>  I did a standard newfs  ( newfs /dev/da1s1e and newfs
> /dev/da1s1d ) before the journaling. After I edited
> the bsdlabel to have the 16 offset.
> 
>  I have seen that there is a newfs -J, however I am
> uncertain of its usage (or what it does) if one is
> using a separate (beginning) slice for the journal.
> 
> Per Pawel, it seems perhaps my test is flawed. However
> I would swear that doing this test before, showed an
> improvement, not decrease. Hence I wonder if there has
> been some recent change in 6-STABLE such that it does
> not integrate as well somehow.


The comments above are exactly why the details on configuration are 
important.  You'll find better performance if you can put the journal on 
a different disk than the data.


>>>  Any suggestions on why this could be happening
>>> greatly appreciated.
>>>
>>>  tested via 
>>>  dd if=/dev/zero of=./testfile bs=16 count=16384
>> A 16byte block size is, well, really not going to
>> prove much.  Try a 1m 
>> block size.
> 
>  If I were using larger files, perhaps. But I store
> many smaller files, so this seems much more realistic.
>  I will perhaps try some slightly larger sizes.

Which is why your test is not indicative of your real use.  You are 
sending sequential writes to the disk, when you really are using it in a 
more random fashion.  You should probably use iozone, or craft a simple 
loop around a bunch of dd commands that do single files each, or something.


>>>  On 2 different dual opteron systems with 8 gigs
>> of
>>> Ram running FreeBSD 6.2-STABLE amd64 (as of 4 days
>>> ago)
>>>
>>>  Regardless of the disk (I tested scsi and ata and
>> one
>>> on a raid controller) both times I converted it to
>>> journal, the speed went in half. 
>> Half of what, down to what?
> 
>  Why does that matter? If its 1/2, why does it matter
> what it is 1/2 of?


It's another data point.  If you want help debugging something, it 
doesn't hurt to include extra information, whereas arguing about whether 
it's important or not is kind of a waste of time.. :(



>>>  With disks getting larger and larger, why is it
>>> taking so long for a journaled filesystem to be
>>> standard on BSD?
>>
>> Since we've had soft-updates for quite some time, it
>> has reduced the 
>> need for a journaled file system, however it is of
>> course increasingly 
>> important.  I suppose one has not happened yet
>> because not enough 
>> developers have had the spare time to implement one.
>>  Besides, in 
>> 7-RELEASE, you'll have zfs, so there will be an
>> option for you.  You can 
>> always submit patches for journaling for one of the
>> existing file 
>> systems if you'd like.
> 
>  That assumes that I am a developer with such skills.
> People always saying, then submit a patch, assumes one
> has the skills and time to do so. I, and most
> companies, would rather pay to have someone who has
> the specialized skills to do the job well. I, and my
> company contribute money to BSD, as that is the
> resource we have available. I have seem some people
> solicit money requests to do enhancement work etc..
> Usually with good results. It seems to me, more would
> get done that way than always assuming anyone who
> knows how to use freeBSD well and or post on the
> mailing list, has the ability to also write code for
> it.
>  (my tiny rant)


Understood.  I wasn't trying to say 'do it yourself', I don't know your 
skill level. I'm just saying if someone wants it, they should contribute 
to the effort - be it code, support, money, advocacy, etc.  Sounds like 
you are doing well to contribute with your company.

What I recommend, is if it is important to you, get your company to put 
up a bounty for what you want.  Other companies/individuals may also 
chip in and add to your bounty.  Look at the rsync.net site for a great 
example.

Eric