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. 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. -- 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
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:54 UTC