Path: utzoo!attcan!uunet!samsung!sdd.hp.com!uakari.primate.wisc.edu!zaphod.mps.ohio-state.edu!mips!sgi!vjs@rhyolite.wpd.sgi.com
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Newsgroups: comp.protocols.nfs
Subject: Re: NeFS protocol
Message-ID: <61077@sgi.sgi.com>
Date: 27 May 90 21:59:12 GMT
References: <1990May24.034258.13625@Neon.Stanford.EDU> <3378@auspex.auspex.com> <265DFAD2.5818@intercon.com>
Sender: vjs@rhyolite.wpd.sgi.com
Organization: Silicon Graphics, Inc., Mountain View, CA
Lines: 61

In article <265DFAD2.5818@intercon.com>, amanda@mermaid.intercon.com (Amanda Walker) writes:
> Flexibility wins.  This is probably even more true for file service than
> for display service...
> Amanda Walker, InterCon Systems Corporation

Yes, but only when all else is equal.  Unfortunately, things are rarely equal.

I've been thinking about why people have been saying the idea behind NeFS
is good, that sending "programs" is better than sending requests.  There
seem to be two justifications for this claim.  First is that high latency,
high bandwidth networks do not like round trips.  Second are varitions of
the flexibility arguement.

Concerning the first, I know of a Distribute Graphics Library that is
required to look like a certain Graphics Library, on which applications in
C, Fortran, Ada, etc. like to make >100,000/sec calls like
"drawfoo(x,y,z,r)".  This DGL library now runs at >20,000 "remote
procedure calls"/sec over ordinary ethernet.  As far as the application
program is concerned, it is simply linked with a different graphics
library.  There are not 40,000 ethernet packets/sec, but the details are
irrelevant.  The point is that at 20,000 "RPC's" second, an ethernet looks
like a high latency network.  Also, at 200,000 to 1,000,000 GL calls/sec,
we don't have a lot of time for compiling requests.  Yes, there is work on
"higher level" stuff, but that is irrelevant for my point, that high
latency is not antithetical to "RPC".

The most common failing in systems' designs are expressions of the
designer's inability to so say "no".  Here the flexibililty argument
is a good way for file system designers to avoid designing the file system,
to avoid doing the hard thinking and making the hard choices in caching,
naming, locking, and so on.  In practice, it seems all agree that humans
will not write PostScript requests, that something will be compiling from
something else.  It is clear to me that for at least a few years we will
not have the CPU cycles for file system clients to be doing the equivalent
of SQL query optimization at a rate of one compilation of request to
Postscript per file open-access-close, or even of one compilation per human
interaction.

It is more likely that there are a modest number of requests that any and all
applications will ever make of remote, high latency file systems, and
that these requests will be written and compiled exactly once, like
rpcgen/XDR/etc of old.  Rather than using a Turing-complete language like
PostScript for a finite number of requests, a good designer would design a
good, extendable (not extensible) protocol for the job.

I designed and implemented a fancy WISIWYG, extensible, oject oriented,
device independent, text preparation system, complete with internal
description language for extensibilty for my employer-before-last.  It was
a mistake since the number of people interested and able to use the
language was insignificant.  It did allow quicker implementation, but that
had nothing to do with having J. Random Oem, let alone T.Arb.User,
use the language.  The same will apply to NeFS.  It is almost true of NeWS.

PostScript is a good page description description language.  Perhaps it
will be a good file system language, when the relative latency of the
network to the CPU is like that between troff/CPU and Apple Laserwriter, a
lot worse than 50 MIPS vs. 30 msec, and more like printings' 5 MIPS vs. 5 sec.


Vernon Schryver
vjs@sgi.com