|
|
-----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-----
|
|