-----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@jabber.org
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-----