Date: Mon, 07 Apr 1997 19:05:19 -0700 From: John Heidemann <johnh@ISI.EDU> To: Michael Hancock <michaelh@cet.co.jp> Cc: fs@freebsd.org Subject: Re: NFS bypass op and the utok layer Message-ID: <199704080205.TAA10123@dash.isi.edu> In-Reply-To: <Pine.SV4.3.95.961113233409.14783F-100000@parkplace.cet.co.jp>
next in thread | previous in thread | raw e-mail | index | archive | help
A long time ago, on Wed, 13 Nov 1996 23:49:43 +0900, Michael Hancock wrote: >Subject: NFS bypass op and the utok layer > >Were these even considered when the FreeBSD vnode stacking implementation >was done? > >The NFS default op is the one returning the NOT SUPPORTED error. A bypass >op would allow you to stack on top of an out-of-kernel layer which could >then be layered on a utok layer to cross the boundary again. > >I guess the fs memory allocation architecture is not compatible with this. > >Debugging in userland would sure be cool, when you're satisfied take away >the transport layers and you're back in the kernel. >... >Mike Hancock NFS bypass and user-level debugging were considered in the context of the initial stackable filing implementation under SunOS. See <http://www.isi.edu/~johnh/PAPERS/Heidemann94a.html>; for a description. The scenario you describe (moving layers in and out of the kernel) was in regular use from about 1990-1995 at UCLA. Unfortunately, the FreeBSD port of stacking included only the in-kernel portions. At the time the NFS code required Sun's XDR implementation. There many possible design trade-offs in the approach. We had NFS as our kernel-to-user transport layer and a custom user-to-kernel transport layer. The disadvantage with our approach is that NFS munges all the operations, making them stateless and in general giving you a different operation mix at user-level than in the kernel. The big advantage is that the NFS client-side of the user-to-kernel transport provides caching and deals with all of the memory allocation problems you allude to. Other design points (such as having custom transport layers in both directions) have other trade-offs, of course. I actually re-implemented the NFS-bypass code after the FreeBSD port, making it freely available and more flexible but slower. (Slower XDR code than Sun's---hard to believe, I know, but think of it as a research prototype. The speed could be much improved with different design decisions.) A port of this later work to FreeBSD and a FreeBSD-based user-level file-system development envrionment would be kind of cool, if anyone's interested. -John ``not reading this mailing list often enough'' Heidemann
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704080205.TAA10123>