From owner-freebsd-hackers  Mon Aug 21 07:24:10 1995
Return-Path: hackers-owner
Received: (from majordom@localhost)
          by freefall.FreeBSD.org (8.6.11/8.6.6) id HAA22040
          for hackers-outgoing; Mon, 21 Aug 1995 07:24:10 -0700
Received: from time.cdrom.com (time.cdrom.com [192.216.222.226])
          by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id HAA22034
          for <freebsd-hackers@freebsd.org>; Mon, 21 Aug 1995 07:24:06 -0700
Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.11/8.6.9) with SMTP id HAA11066; Mon, 21 Aug 1995 07:23:50 -0700
To: peter@haywire.dialix.com (Peter Wemm)
cc: freebsd-hackers@freebsd.org
Subject: Re: Making a FreeBSD NFS server 
In-reply-to: Your message of "21 Aug 1995 22:09:12 +0800."
             <41a428$1aa$1@haywire.DIALix.COM> 
Date: Mon, 21 Aug 1995 07:23:50 -0700
Message-ID: <11064.809015030@time.cdrom.com>
From: "Jordan K. Hubbard" <jkh@time.cdrom.com>
Sender: hackers-owner@freebsd.org
Precedence: bulk

> - The data was copied back and forward from the client's user space
> and the server with remote copyin/copyout.
> - It *guaranteed* proper unix semantics on the remote fs... none of
> the kludgey stuff that NFS has to do..

There are better ways of doing this, BTW..  A company I used to work
for (Periphere Computer Systeme, GmbH) had something they called
MUNIX/NET which did all of the above and at very reasonable speeds.
Even then, many people praised MUNIX/NET as a superior solution to the
whole file sharing problem, even if it did require kernel modification
on both the server and client ends.  It basically used the "superroot"
model for addressing other machines (/../machine/file) and you could
talk to everything from files to tape drives remotely - something you
can't do with NFS.  Since you could also traverse mount points
successfully on the local machine, you got around that particular
foible of NFS as well.

OK, so it wasn't stateless, but I don't seem to recall any big
problems caused by this when I used it.

There was also a pretty powerful uid mapping system for telling it
which uids you wanted mapped straight across, which you wanted
translated, etc.  It's actually one of those systems who's merits I
didn't really appreciate at the time but did in retrospect.. :-(

> This might be fun to implement one day for a FreeBSD "cluster"...
> Providing it's done right, of course, and isn't "marketed" as a
> generic network filesystem like AT&T's droids tried.

Some PCSers here talked about resurrecting MUNIX/NET and bringing it
back to life on FreeBSD, but I don't think that the legal powers were
ever willing to open the doors enough to allow it, so I suspect that
MUNIX/NET will die along with BETAMAX and OpenLook.  Good solutions
shot dead by mediocre solutions with bigger guns.. :-)

					Jordan