[comp.sys.mac] NFS and Mac IIs

time@oxtrap.sendai.ann-arbor.mi.us (Tim Endres) (07/19/89)

>> Many questions concerning MacNFS

Being the original author of MacNFS at CITI UofM, maybe I can clear
some things up.

One) MacNFS versus AppleShare

   When we started the MacNFS project more than three years ago, we
had to chose between implementing NFs protocols on the Mac or
implementing AppleShare protocols in Unix. We chose to implement the
NFS protocols on the Mac for "open-systems" reasons. CAP implemented
the AppleShare protocols (and nicely I might add).

   AppleShare will ALWAYS beat NFS protocols for the Macintosh.
Without getting too deep into details here, suffice it to say that the
mapping of Macintosh files to the Unix domain is not a simple task.
You must keep tracks of the three forks (Data, Resource, Finder).
You must answer many "very brain-damaged" interface calls. The biggest
head-ache was the repetetive "GetFileInfo()" in "index-mode" that
killed any file server whenever the Finder went into its display mode.

   Since the NFS protocol was/is (and for good reason) limited, we
had to make *many* network calls to NFS to implement even a *single*
GetFileInfo() call. AppleShare, on the other hand, gets the
complicated Macintosh calls on the Unix side, completes any necessary
"kludges" on the Unix side and returns the answer !All in one network
call!. So MacNFS will never compete with this advantage.

Two) Where is MacNFS

   Well, you can blame 9 months of its delay on Bert Herzog at CITI!
He sat on finished, released code and documentation for 9 months,
because "I don't know who to send it to at Apple.". Thanks Bert.

   Apple seems unprepared to meet an original deadline for the release
of MacNFS. Why? Well, I could never get it to work 100%!!!
We did not have the Finder source code, and the Finder did things that
did not match the IM docs, and we could get no answer from Apple
Support. I would have thought that internally they could produce this
themselves, but apparently they understand their code very little. Or,
there are other reasons, I can NOT speak for Apple. MacNFS is a very
complicated beast, even if you have source to the Finder and MacOS.

Three) Do you *really* want MacNFS

   YES you do. It may not be the best performance package but it is on
every unix box going. CAP is a *very* good facility, but not commercial.

Apple, please get MacNFS out in the hands of your users. It has been
stalled long enough. It seems a shame for such a large amount of work
(paid for by Apple) to sit on a shelf.

Tim Endres.

tim@hoptoad.uucp (Tim Maroney) (07/20/89)

Thanks to Tim Endres for his very informative message on MacNFS.  It
may be of interest to some people that TOPS, A Sun Microsystems
Company, was slated from the time of the acquisition by Sun to produce
a Macintosh NFS, and to replace its current product TOPS with this
Macintosh NFS.  Last year, this attempt was abandoned.  There are
simply too many technical obstacles to producing a good NFS client or
server that is compatible with the Macintosh file system.  The
efficiency constraints imposed by the RPC model are one major problem;
the lack of flexibility of the NFS protocol is another.

TOPS did negotiate with Sun over changes in the NFS protocol that
would allow efficient operation with the Macintosh file system.
However, these negotiations came to naught because of blocking
on the Sun side.

There never will be a good Macintosh NFS product, without major changes
to the NFS protocol.  Those changes will not happen.

I don't mean to sound like a broken record here, but the fact is that
NFS is *not* well suited to inter-operating-system environments.  It
works very well between UNIX systems, tolerably well between UNIX and
the similarly ultra-simple MS/DOS file system.  It does not work well
when there is a complex file system like Macintosh or VMS involved.
It can be made to work, but only with a great deal of difficulty and
a very user-visible performance penalty.  The supposedly inter-OS
nature of NFS is a fabrication (albeit a sincere one) of starry-eyed
Sun engineers; this aspect of the protocol was announced long before
even a single non-UNIX implementation was done.
-- 
Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com

"There are no Famous People on the net.  Only some of us with bigger mouths
 than others."  -- Dan'l Danehy-Oakes, The Roach

amanda@intercon.uu.net (Amanda Walker) (07/20/89)

In article <8058@hoptoad.uucp>, tim@hoptoad.uucp (Tim Maroney) writes:
> There never will be a good Macintosh NFS product, without major changes
> to the NFS protocol.  Those changes will not happen.

This seems a little strong.  I would agree that there will never be a good
*simple* NFS product for the Mac without protocol changes, because there
is not a simple mapping between the Macintosh file system and a UNIX-style
file system (or much of anything else, for that matter :-)).  However, I
think that products like AUFS, the GatorBox, and others have shown that
it is possible to do it acceptably well.  The biggest problem I can see in
implementing a good native Mac client NFS is simply one of size.  Not because
of RPC & XDR, which aren't too bad if you look at them as notational aids
rather than implementation specs, but because the client code will have to
maintain a fair amount of local state in order to buffer things well and avoid
lots of network traffic.  With UNIX or MS-DOS, you can get by with a pretty
dumb client.  With the Mac OS you have to do more work, which has good points
and bad points, one of the bad points being that it will take longer to do
well.

NFS in general is all too healthy, and eventually someone will take the time
and money to do a good Macintosh implementation.  It would be nice if this
"someone" turned out to be Apple, but I'm reserving judgement for now.

Sigh.

--
Amanda Walker
InterCon Systems Corporation
--
amanda@intercon.uu.net  |  ...!uunet!intercon!amanda

amanda@intercon.uu.net (Amanda Walker) (07/20/89)

I'd like to add to an article I just posted, in which I responded to Tim
Maroney and said that a good native Mac NFS client is possible, even if
difficult.  After discussion with one of my co-workers, it occurred to me
that this article might have given the impression that I think that such a
product would be a good thing.

I do not.

NFS is barely capable of supporting a UNIX workstation, and as long as that's
what it is used for, it's not too annoying.  However, it doesn't even provide
full UNIX file system semantics, much less anything approaching the Macintosh
file system.  Granted, this can be worked around by putting more code into
the client, but this has it's own disadvantages.

Even though it provides a usable interim file service solution for Sun, I
would not recommend that anyone use it for Macintosh file service, at least
in any more serious way than as a convenient way to transfer files between
machines.

Just thought I'd set the record straight :-).
--
Amanda Walker
InterCon Systems Corporation
--
amanda@intercon.uu.net  |  ...!uunet!intercon!amanda