Arla on FreeBSD

Tomas Olsson tol at it.su.se
Thu Feb 15 10:16:06 UTC 2007


Kostik Belousov <kostikbel at gmail.com> writes:
> > I'm already funded and can work full time on this, but a FreeBSD hacker
> > would help a lot.  Any volunteers?
> 
> Sorry for me pointing out obvious, why not continue to use fs@ as place
> where to ask ?
>
You're very right, I'm just to shy to do it... Thanks.

Anyway;

Arla is built around a "small" caching fs driver (nnpfs) servicing user
requests by asking the 'arlad' daemon for help or just operating on local
files created/fetched by arlad. They communicate over a char device.

A simple read would be handled as such:
        getnode/getdata rpc to arlad
        installnode/installdata + wakeup msgs from arlad
        VOP_READ() on newly fetched cache file

Subsequent reads on the same data would skip the rpc part, unless arlad has
invalidated the node.

Previously, there was a 1:1 mapping between nnpfs vnode and cache file. The
installdata message was then handled by fetching the cache file's vnode (in
arlad's context), storing it in the nnpfs_node for future reference/access.
Now we ended up with one cache file per "block" (large) of data, and
decided that it would be better to open/access/close the cache "block" file
on each access.  The closest we could get to the olden ways was to open the
directory where a node's cache blocks reside, in arlad's context.

The interesting part is how we open and access the cache files, and from
what context. arlad is in chroot() to avoid recursive lookups across /, and
it seems like a good idea to avoid such lookups now too.

So the main question is how to properly do VOP_{LOOKUP,CREATE,WRITE} etc on
cache files in this dual context world, without mixing identities in bad
ways or confusing the OS too much.

The currently messed up code lives in
http://cvsweb.stacken.kth.se/cvsweb.cgi/arla/nnpfs/bsd/

Most interesting is nnpfs_vnodeops-common.c (nnpfs_write_common()) and
nnpfs_blocks.c (open_file())

thanks
        /t


More information about the freebsd-fs mailing list