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,