Subject: Re: Fwd: A JBD file-system (generic Journal file for ext2)
To: Avinash Malik <>
From: Bill Stouder-Studenmund <>
List: tech-kern
Date: 09/22/2007 23:07:22
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sun, Sep 23, 2007 at 03:30:32PM +1200, Avinash Malik wrote:
> Hello,
>      I have been implementing the journaling,
> I had a few questions
> 1.) Say when I am committing (which is being done on a separate lwp than =
> transactions), my current implementation first gets the transaction to be
> committed. Checks If there is enough space in the log, If there is then a=
> of the transaction is made. This copy is then sent to the commit-func-poi=
> to be written to the journal. Fine, this is the normal case.
> 2.) When there is not enough space in log. I call the check-pointing rout=
> instead of the committing routine, which flushes (not yet implemented)
> everything from log onto disk.

I think you're putting the cart before the horse. Figure out how to write=
data to the journal correctly & subsequently out to disk. Then talk about=
how to make it faster. Since you haven't written code yet, it's not clear=
that a separate thread really will help, or that it will help the most.

> Question:
> 1.) Is there a need to kick a waiting thread on mutex using condvars. Bec=
ause I
> have a committing function which is waiting on journal-mutex and the call=
> thread first acquires that journal-mutex, makes the transaction copies et=
> and then exits it. Logically this should work fine since once the calling
> ufs_thread exits mutex commit-lwp should obtain it correct? So no need fo=
r me
> kicking the commit thread with condvars....

You have to wake the condvar. That's how they work. If the thread is=20
waiting to lock the mutex, it may get the mutex once its released. However=
if you're waiting on a condvar, you wait until your awoken.

> 2.) A trivial question, the blkroundup macro in /sys/ufs/ext2fs.h takes t=
> size,fs and gives back size out. From what I can make out, say if buf has=
> data size of 9-bytes and blocks in the fs were 2-bytes each then the retu=
> size would be 10-bytes (i.e. rounded up to the block-boundary correct?)

Yes, however you should never need to use that code. Everything that gets=
sent to the journal should already be a block.

Take care,


Content-Type: application/pgp-signature
Content-Disposition: inline

Version: GnuPG v1.4.7 (NetBSD)