fa.netbsd.tech.kern
[Top] [All Lists]

Re: A JBD file-system (generic Journal file for ext2)

Subject: Re: A JBD file-system generic Journal file for ext2
From: Adam Hamsik
Date: Fri, 21 Sep 2007 09:56:12 UTC
Newsgroups: fa.netbsd.tech.kern


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Sep 21, 2007, at 5:18 AM, Bill Stouder-Studenmund wrote:

On Thu, Sep 20, 2007 at 04:36:59PM +1200, Avinash Malik wrote:
Hello,
after thinking about the various journaling requirements this is what 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 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 using 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
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"
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 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
our on-disk format were close enough (or someone added support) and we
added LVM support, we could handle IBM's jfs.

Yes I think that when we will have working ext3 fs we can export
jbd functions away from ext3fs filesystem and use it as separate lib.

Because there are other filesystems which are based on jbd AFAIK ocsfs,ocsfs2,ext4.


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
blocker. We can work on that once we have a journal implementation that
actually works.

Also in the commit function is where we also do check-pointing if the required
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
much to the journal". This is needed so that the calling operation can
break its operation up into smaller chunks. This is essential for say
deleting too large a file; the metadata change can easily be larger than
the size of the journal.

In my haad.ext3fs branch I have added new fs specific structure to trans_attr we can use this to keep information about max journal size. because it is filesystem specific.

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

Regards
- -----------------------------------------
Adam Hamsik
jabber: haad@xxxxxxxxxx
icq: 249727910

Proud NetBSD user.

We program to have fun.
Even when we program for money, we want to have fun as well.
~ Yukihiro Matsumoto




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

iD8DBQFG832glIxPgX3Go0MRAhwzAJoC2RJ80YcbIp0LAuHfvdiJxmlVpACfXjdN
NIJnwdfvI8xm8Ppxlaue1YE=
=hQvx
-----END PGP SIGNATURE-----

<Prev in Thread] Current Thread [Next in Thread>