Date: Sat, 22 May 2004 18:54:04 -0400 From: Allan Fields <bsd@afields.ca> To: Brooks Davis <brooks@one-eyed-alien.net> Cc: freebsd-current@freebsd.org Subject: Re: GEOM portable filesystem abstraction? Message-ID: <20040522225404.GA23275@afields.ca> In-Reply-To: <20040520191910.GB28688@Odin.AC.HMC.Edu> References: <c8iu9o$jd9$1@sea.gmane.org> <20040520191910.GB28688@Odin.AC.HMC.Edu>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040522225404.GA23275>