Hello,
     I have been implementing the journaling,
I had a few questions
1.) Say when I am committing (which is being done on a separate lwp than adding
transactions), my current implementation first gets the transaction to be
committed. Checks If there is enough space in the log, If there is then a copy
of the transaction is made. This copy is then sent to the commit-func-pointer
to be written to the journal. Fine, this is the normal case.

2.) When there is not enough space in log. I call the check-pointing routine
instead of the committing routine, which flushes (not yet implemented)
everything from log onto disk.

Question:

1.) Is there a need to kick a waiting thread on mutex using condvars. Because I
have a committing function which is waiting on journal-mutex and the calling
thread first acquires that journal-mutex, makes the transaction copies etc...
and then exits it. Logically this should work fine since once the calling
ufs_thread exits mutex commit-lwp should obtain it correct? So no need for me
kicking the commit thread with condvars....

2.) A trivial question, the blkroundup macro in /sys/ufs/ext2fs.h takes the
size,fs and gives back size out. From what I can make out, say if buf has valid
data size of 9-bytes and blocks in the fs were 2-bytes each then the returned
size would be 10-bytes (i.e. rounded up to the block-boundary correct?)


regards,

Quoting Avinash Malik <amal029@ec.auckland.ac.nz>:

> Quoting Bill Stouder-Studenmund <wrstuden@netbsd.org>:
>
> > 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.
>
> Just to make my understanding clear before I get into coding it, this is what
> I
> understand from the above statement:
>   The commit functionality will still be implemented as a function in the
> file-system, and there will be host of commit functions one for each
> Journal-type, depending upon how many journaling type each file-system wants
> to
> support. The ufs_trans_attr structure containing the gj_commit function
> pointer
> will point to the appropriate journal commit function (which is implemented
> in
> the file-system) and this gets initialized as it is being done right now
> correct?
>
> >
> > 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.
> >
> > 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.
> >
> > > 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
> >
>
>
> I don't know if this is the right place to ask this question but, normally I
> use
> Freebsd and I installed NETBSD-3.1 to start-coding, everything went normally
> until it came to networking when I dhclient rtk0, I get an IP but no netmask
> at
> all it remain at 0xfff..000. It is a real hassel using freebsd to import the
> packages on disk and then booting into NETBSD to start coding. Any help with
> regards to this is appreciated. I tried static IPing the interface, it does
> the
> same thing, command "ifconfig rtk0 down ; ifconfig rtk0 10.1.1.4 netmask
> 255.0.0.0" goes through but netmask does not get assigned at all remains same
> to 0xff..000.
>
> cheers,
>
>