Date: Tue, 8 Apr 1997 14:22:39 +0900 (JST) From: Michael Hancock <michaelh@cet.co.jp> To: John Heidemann <johnh@ISI.EDU> Cc: fs@freebsd.org Subject: Re: NFS bypass op and the utok layer Message-ID: <Pine.SV4.3.95.970408141934.8609A-100000@parkplace.cet.co.jp> In-Reply-To: <199704080205.TAA10123@dash.isi.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 7 Apr 1997, John Heidemann wrote: > 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 I'd like to have a look. Are you volunteering or are you looking for volunteers? Regards, Mike
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SV4.3.95.970408141934.8609A-100000>