--FmdPcZLZZW6lDAYm
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Sep 20, 2007 at 04:36:59PM +1200, Avinash Malik wrote:
> Hello,
>      after thinking about the various journaling requirements this is wha=
t I can
> come up with, correct me if I am wrong
>=20
> 1.) We still call the commit process from ufs_commit to fs_commit, but on=
 a
> writer thread. But before calling this fs_commit function we make a copy =
of
> trans_attr and use the new copy for fs-transactions. The old copy is used=
 for
> committing. Now since, the jbd thread is calling the fs_commit function u=
sing a
> 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.=
=20
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=
=20
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=
=20
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
actually works.

> Also in the commit function is where we also do check-pointing if the req=
uired
> number of blocks exceeds the number of free blocks in the log.

Yes.

We will also need a way to indicate that "you will never get to write that=
=20
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,=
 we can
> have same functionality as linux but with support for multiple Journaling
> systems.

That's the goal!

Take care,

Bill

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (NetBSD)

iD8DBQFG8zgNWz+3JHUci9cRAnGPAJ4qqAD9IHB2m4jfDoxbhA2JkjawewCeOWmt
+Oh+po3KF1hAZJ4XworiNn4=
=Ej5S
-----END PGP SIGNATURE-----

--FmdPcZLZZW6lDAYm--