Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 4 Feb 2009 23:18:24 -0500
From:      Gabriel Lavoie <>
To:        Manolis Kiagias <>
Cc:        FreeBSD-Questions List <>
Subject:   Re: GEOM_JOURNAL on a 550G partition - opinions ?
Message-ID:  <>
In-Reply-To: <>
References:  <> <>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
    two 500gb hard drives under gmirror/gjournal and no problem here.
I've had a few problems with the root partition under gjournal in
FreeBSD 7.0. With an unclean shutdown, the journal replay wasn't done
quickly enough before the kernel tried to mount the root partition,
failing to do so because the device node is only created after the
journal has been replayed. I reported the bug and it has been
corrected in HEAD but I don't know if the correction made its way on
7.1. So, my / partition is on gmirror only with soft-updates and the
rest of my system has gjournal on top of gmirror. Made a lot of test
by resetting the system and removing/putting back a hard drive and the
system always came back in a clean state.


2009/2/4 Manolis Kiagias <>:
> Hugo Silva wrote:
>> Hi list,
>> For a server I will be setting up, I am considering using gjournal on
>> the partition that will hold all the www data.
>> The journaled partition (mounted async) would be mostly read from,
>> uploads would not be very frequent and most sites wouldn't write to
>> the disk. Logs would be kept elsewhere.
>> This server will have two hard disks, mirrored (gmirror) at the disk
>> level.
>> Here are my questions:
>> - Will the fact that gmirror is underneath the journal
>> (/dev/mirror/gm0s1f.journal) affect performance ? (either positively
>> or negatively)
>>   (* I would be keeping the journal in the same provider)
> I can only tell you this works. Have not done any real measurements on
> this stuff, as most of my systems are normally not under high load.
> I've done this for a friend's SAMBA server, who is storing very large
> photo files all the time.  In fact, I am just preparing our local LUG
> server in exactly this way.
> At least in theory gmirror can be set to balance (round-robin) reads
> from the disks, so read should be improved. On the other hand, the
> journaling implementation in gjournal writes everything twice, so expect
> to have some significant overhead there.
> Ivan Voras has done some performance testing on several filesystems,
> including UFS with soft updates and journaling. See the results in this
> post:
>> - Would reads / writes be faster? considerably faster ? (gjournal)
>> I've seen different numbers from different places, the impression I
>> got is that reads should be faster while writes will be substantially
>> slower - is this correct ?
> It seems so, at least for the writes.
>> - What about reliability ? From the manpage, I know that if I
>> journaled the entire mirror, I would not need to sync it after an
>> unclean shutdown.
>>   Going from the assumption that this will not be so for a single
>> journaled partition, will there be any interference between gjournal
>> and gmirror ?
> I haven't had any reliability problems combining gmirror and gjournal.
> To my experience, gjournal syncs the gmirror almost instantly after an
> unclean shutdown.
>> - I've never had an UFS2 partition filled with more than 200G of data,
>> so I am not sure what to expect for 550G with soft-updates (I expect
>> this partition to hold close to 550G of data) - real numbers about
>> this would also be helpful.
>> Any personal experiences concerning gjournal or gmirror+gjournal are
>> greatly appreciated!
> As I said, I've been using both (and combined) for quite some, and
> haven't faced any problems caused by the software.  I even recovered
> from a serious hardware problem, without losing any data. For
> performance measuring I guess you would have
> to setup a test system and see by yourself if it is acceptable.
> _______________________________________________
> mailing list
> To unsubscribe, send any mail to ""

Gabriel Lavoie

Want to link to this message? Use this URL: <>