Re: GEOM portable filesystem abstraction?

On Thu, May 20, 2004 at 03:49:44PM -0400, Jesse Guardiani wrote:
> Brooks Davis wrote:
> 
> > On Thu, May 20, 2004 at 02:44:06PM -0400, Jesse Guardiani wrote:
> >> Hello,
> >> 
> >> I know next to nothing about GEOM, other than what
> >> the man page says (which I admittedly didn't read
> >> in full), so I'm probably totally off base, but I
> >> thought I'd ask this anyway:
> >> 
> >> 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?
> >> 
> >> 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.
> >> Perhaps if GEOM were ported to Linux then Linux
> >> could use FreeBSD's UFS2 code to read FreeBSD UFS
> >> filesystems? Perhaps a windows and MacOSX GEOM kernel
> >> module could follow?
> >> 
> >> Is that entirely too far fetched?
> > 
> > Yup. :-)  The problem with this idea is that while GEOM handles disk
> > geometry translations, file systems are consumers of GEOMs not actual
> > GEOM modules.  All GEOM does from the file system's perspective is
> > present an array of bytes.  I suppose if you ported GEOM and brought all
> > the interaction semantics along you could get some portability, but I'm
> > not sure GEOM would actually be any help here.
> 
> Well, if every OS looks at the disk in a different way, and you must
> manipulate the disk directly to implement things like GBDE encrypted
> filesystems, then would it make sense to port GEOM and simply build
> yet another abstraction layer for filesystems on top of it?
>
> Two layers of abstraction might not be too much...

Porting GEOM to other OSes could certaintly be useful.  It's definatly a
nice concept.

> > 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.
> > 
> > http://www.cs.columbia.edu/~ezk/research/fist/
> > 
> > Currently, fist is used to implement stacking layers, but I imagine
> > you could write a full-fledged files system in it, possiably after
> > extending it a bit.  I'm not actually sure though.
> 
> That's interesting. It's too bad I'm not knowledgable enough as
> a programmer to write filesystems. That would make a killer project.
> 
> I'm not sure a new "language" to describe filesystems would be appropriate
> though. I think that might be too much abstraction, resulting in massive
> loss of performance.

Ideally you'd like a file system that was fast, portable, and
maintainable.  I'm not sure all three are really feasiable unless you're
really careful about defining portable so the OSes in question have a
decent set of common VM semantics available with reasionable overhead.
That's not to say we can't dream or that research shouldn't be done in
this are, but I think we're definatly in research land here.

-- Brooks

-- 
Any statement of the form "X is the one, true Y" is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529  9BF0 5D8E 8BE9 F238 1AD4