Re: GEOM portable filesystem abstraction?

On Thu, May 20, 2004 at 12:19:12PM -0700, Brooks Davis wrote:
> On Thu, May 20, 2004 at 02:44:06PM -0400, Jesse Guardiani wrote:
> > 
> > It seems like GEOM functions as a bit of a disk
> > abstraction layer in FreeBSD. Would it be possible
> > to port the GEOM subsystem as a loadable kernel
> > module to Linux (and perhaps other OSes) to
> > facilitate pluggable, portable filesystem code?

It's interesting to note the similarities in the approaches GEOM
and vnode stacking take:  Both can act to transform data before
reaching disk; both are modular "object oriented" interfaces which
can be manipulated at system runtime; both aim to implement DAGs
and allow free interconnection of components, building up sophisticated
behaviour.  There are implementations of disk encryption and
replication schemes at both levels, etc.

> > I'm constantly frustrated by the fact that Linux and
> > BSD are OPEN SOURCE OSes, but they *still* can't
> > write each other's file systems any better than they
> > can write the reverse engineered NTFS filesystem.

Good point, I'd think most file system developers have their hands
full developing for a single platform, but cross-platform function
is a desirable goal.  The fact that file system code is complex and
closely integrates with other sections of the kernel impedes portability.

But I'd rather have a high performance filesystem on a single platform
if portability meant a significant hit in performance.

> FWIW, fist does provide a set of portable semantics and if you wrote a
> real file system on it, it should work on FreeBSD, Linux, and Solaris.

However, larger cross-platform compatibility isn't yet a reality
with current fistgen templates.  It will take more work (though the
potential is real and with-in reach):

* Some issues remain w/ FreeBSD templates, but mostly they work under
FreeBSD 4 & 5 with some minor tweaks to compensate for incremental
changes to the vnode interface.

* Even on the Linux side, various kernels are better supported
than others at this point in time.  To the best of my knowledge
there are no Darwin, NetBSD or OpenBSD templates; porting to Windows
raises a host of issues.

> http://www.cs.columbia.edu/~ezk/research/fist/
| http://www.filesystems.org/
> 
> Currently, fist is used to implement stacking layers, but I imagine
> you could write a full-fledged files system in it, possibly after
> extending it a bit.  I'm not actually sure though.

This is still an open question as to whether it's practical and
others had mentioned the possibility..

What FiST does provide is the top-half of the solution: I'd be interested
to hear if anyone manages to build a full filesystem using the framework
provided to attach custom filesystem code which implements it's own
"back-end".

Unfortunately, much of the desired portability might be sacrificed
in such an exercise as you then are going past the common vnode
interfaces and implementing routines that have to cooperate with
other parts of the kernel.  

FiST allows arbitrary code to be hooked into vnop calls, but
usually these are auxiliary functions: for example, used in
transforming data before passing to the lower-vnode, etc.

Generalization of FiST beyond stackable file systems is an interesting
idea, perhaps one that should be followed up on the FiST mailing
list.  Abstracting out all the complexities of file systems would
be a tough challenge, perhaps it's easier to just encourage more
file system ports.

> -- Brooks

BTW, nice clustering paper (just read it earlier today).  Any idea
about state of FreeBSD Condor support and specifically any tid-bits
on kernel support for transparent process checkpointing?

I assume you've been using application-level checkpoints for process
migration.


Thanks..
-- 
 Allan Fields
 Afields Research/AFRSL - http://afields.ca
 BSDCan: May 2004, Ottawa - http://www.bsdcan.org
 2D4F 6806 D307 0889 6125  C31D F745 0D72 39B4 5541