-----BEGIN PGP SIGNED MESSAGE-----
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:
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
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
We won't really have an "ext3fs_commit" but we will have a
for a journal that is layed out how ext3fs/jbd expect.
The reason the file system is involved is only the file system
to figure out what journal is appropriate and where it is. ext3fs
up a ufs_trans journal structure that reads and writes what jbd
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
As to using a thread or whatever, don't worry about that now. There
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.
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
Also in the commit function is where we also do check-pointing if
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
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
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
That's the goal!
jabber: [email protected]
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)
-----END PGP SIGNATURE-----