Subject: Re: Fwd: A JBD file-system (generic Journal file for ext2)
To: Avinash Malik <email@example.com>
From: Bill Stouder-Studenmund <firstname.lastname@example.org>
Date: 09/20/2007 20:18:37
Content-Type: text/plain; charset=us-ascii
On Thu, Sep 20, 2007 at 04:36:59PM +1200, Avinash Malik wrote:
> after thinking about the various journaling requirements this is wha=
t I can
> come up with, correct me if I am wrong
> 1.) We still call the commit process from ufs_commit to fs_commit, but on=
> writer thread. But before calling this fs_commit function we make a copy =
> trans_attr and use the new copy for fs-transactions. The old copy is used=
> committing. Now since, the jbd thread is calling the fs_commit function u=
> func-pointer, from what I understand the fs process will not hang since fs
> itself is not calling the commit functionality.
It's not really "fs_commit". It's "journal format commit" where the=20
journal formats are closely related to specific other fs implementations.=
We won't really have an "ext3fs_commit" but we will have a "jbd_commit"=20
for a journal that is layed out how ext3fs/jbd expect.
The reason the file system is involved is only the file system knows how=20
to figure out what journal is appropriate and where it is. ext3fs will set=
up a ufs_trans journal structure that reads and writes what jbd does. If=20
our on-disk format were close enough (or someone added support) and we=20
added LVM support, we could handle IBM's jfs.
As to using a thread or whatever, don't worry about that now. There are a=
lot of ways we can make actually processing the journal fast and not a=20
blocker. We can work on that once we have a journal implementation that=20
> Also in the commit function is where we also do check-pointing if the req=
> number of blocks exceeds the number of free blocks in the log.
We will also need a way to indicate that "you will never get to write that=
much to the journal". This is needed so that the calling operation can=20
break its operation up into smaller chunks. This is essential for say=20
deleting too large a file; the metadata change can easily be larger than=20
the size of the journal.
> If what I understand is correct (about fs not supsending-see above) then,=
> have same functionality as linux but with support for multiple Journaling
That's the goal!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (NetBSD)
-----END PGP SIGNATURE-----