From mimsy!haven!aplcen!uakari.primate.wisc.edu!brutus.cs.uiuc.edu!apple!sun-barr!newstop!sun!terra!brent Fri Feb 16 03:43:06 EST 1990 Article 796 of comp.protocols.nfs: Path: mimsy!haven!aplcen!uakari.primate.wisc.edu!brutus.cs.uiuc.edu!apple!sun-barr!newstop!sun!terra!brent >From: brent@terra.Sun.COM (Brent Callaghan) Newsgroups: comp.protocols.nfs Subject: NeFS Protocol Spec Available Keywords: NFS version 3 Message-ID: <131732@sun.Eng.Sun.COM> Date: 13 Feb 90 01:57:31 GMT Sender: news@sun.Eng.Sun.COM Lines: 23 NeFS is not NFS. It started out as an NFS protocol rev (NFS version 3) but its protocol is a radical departure from the NFS's remote procedure call model. In order to avoid confusion with NFS we're calling it NeFS for now - Network Extensible File System (the similarity of the name to a window system protocol is entirely intentional). A draft spec for this new protocol is available via anonymous FTP from titan.rice.edu (128.42.1.30) as /public/nefs.doc.ps The file is ~250K of PostScript. It prints 52 pages. The spec is not available in any other format. Comments, suggestions, flames etc are welcomed. Direct them to "nfs3@sun.COM". Thanks Made in New Zealand --> Brent Callaghan @ Sun Microsystems uucp: sun!bcallaghan phone: (415) 336 1051 From mimsy!tank!ncar!asuvax!cs.utexas.edu!uwm.edu!rutgers!bellcore!messy!mo Thu May 24 08:58:10 EDT 1990 Article 1015 of comp.protocols.nfs: Path: mimsy!tank!ncar!asuvax!cs.utexas.edu!uwm.edu!rutgers!bellcore!messy!mo >From: mo@messy.bellcore.com (Michael O'Dell) Newsgroups: comp.protocols.nfs Subject: RE: NeFS protocol Message-ID: <23525@bellcore.bellcore.com> Date: 23 May 90 11:57:34 GMT Sender: news@bellcore.bellcore.com Reply-To: mo@messy.UUCP (Michael O'Dell) Organization: Center for Chaotic Repeatabilty Lines: 20 Dave Clark, Internet Architect, just gave a talk here at Bellcore and he was lobbying for exactly the kind of approach being proposed by the new NeFS protocol - don't send packets, send programs! I do recommend you read the NeFS document and think about it hard before you jump to any conclusions. The proposed model is novel, and goes a long way toward moving us to "action at a distance" instead of "remoting local operations." This turns out to be vitally important if networks are to scale with latency, since, as Dave Clark so eloquently showed, for large networks (ie, country-sized), as bandwidth goes to infinity latency goes to 30milliseconds, and you can't do anything about that, because you can't change the speed of light. So, to do very well in the face of that, you must avoid round-trip delays like the plague. Sending a program to the server can save many round-trips for many operations. Anyway, it is interesting reading. Particularly in light of Dave Clark's talk. -Mike From mimsy!haven!aplcen!uakari.primate.wisc.edu!zaphod.mps.ohio-state.edu!usc!apple!agate!shelby!neon!pallas Thu May 24 08:58:40 EDT 1990 Article 1022 of comp.protocols.nfs: Path: mimsy!haven!aplcen!uakari.primate.wisc.edu!zaphod.mps.ohio-state.edu!usc!apple!agate!shelby!neon!pallas >From: pallas@Neon.Stanford.EDU (Joe Pallas) Newsgroups: comp.protocols.nfs Subject: Re: NeFS protocol Message-ID: <1990May24.034258.13625@Neon.Stanford.EDU> Date: 24 May 90 03:42:58 GMT References: <23525@bellcore.bellcore.com> Organization: Computer Science Department, Stanford University Lines: 13 In article <23525@bellcore.bellcore.com> mo@messy.bellcore.com (Michael O'Dell) writes: >Dave Clark, Internet Architect, just gave a talk here at Bellcore and >he was lobbying for exactly the kind of approach being proposed by the >new NeFS protocol - don't send packets, send programs! The principle is good. The mistake is in the belief that PostScript is a programming language. "Don't send PostScript, send programs!" joe From mimsy!haven!uflorida!rex!samsung!sdd.hp.com!ucsd!ucbvax!agate!shelby!neon!pallas Fri Jun 1 16:58:42 EDT 1990 Article 1029 of comp.protocols.nfs: Path: mimsy!haven!uflorida!rex!samsung!sdd.hp.com!ucsd!ucbvax!agate!shelby!neon!pallas >From: pallas@Neon.Stanford.EDU (Joe Pallas) Newsgroups: comp.protocols.nfs Subject: Re: NeFS protocol Message-ID: <1990May24.205149.6065@Neon.Stanford.EDU> Date: 24 May 90 20:51:49 GMT References: <23525@bellcore.bellcore.com> <1990May24.034258.13625@Neon.Stanford.EDU> <3378@auspex.auspex.com> Organization: Computer Science Department, Stanford University Lines: 17 In article <3378@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: > >The principle is good. The mistake is in the belief that PostScript > >is a programming language. >What exactly is the complaint being made about PostScript here? Programming is a human activity. PostScript is a computer language unsuited to programming. It was designed as a device-independent 2-d graphics representation language, of which it is a nearly adequate instance. People should never write PostScript, however, because anything people write, people must be able to read. joe From mimsy!haven!aplcen!uakari.primate.wisc.edu!ames!sun-barr!newstop!sun!whitsun!pugs Fri Jun 1 17:02:47 EDT 1990 Article 1031 of comp.protocols.nfs: Path: mimsy!haven!aplcen!uakari.primate.wisc.edu!ames!sun-barr!newstop!sun!whitsun!pugs >From: pugs@whitsun.Sun.COM (Tom Lyon) Newsgroups: comp.protocols.nfs Subject: Re: NeFS protocol Message-ID: <136212@sun.Eng.Sun.COM> Date: 25 May 90 01:09:23 GMT References: <23525@bellcore.bellcore.com> <1990May24.034258.13625@Neon.Stanford.EDU> Sender: news@sun.Eng.Sun.COM Lines: 7 In article <1990May24.034258.13625@Neon.Stanford.EDU>, pallas@Neon.Stanford.EDU (Joe Pallas) writes: > > The principle is good. The mistake is in the belief that PostScript > is a programming language. My belief is that PostScript makes a pretty good intermediate language - we just haven't figured out what the high level language should look like. From mimsy!haven!ames!sgi!vjs@rhyolite.wpd.sgi.com Fri Jun 1 17:04:17 EDT 1990 Article 1035 of comp.protocols.nfs: Path: mimsy!haven!ames!sgi!vjs@rhyolite.wpd.sgi.com >From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) Newsgroups: comp.protocols.nfs Subject: Re: NeFS protocol Message-ID: <61061@sgi.sgi.com> Date: 26 May 90 00:37:48 GMT References: <23525@bellcore.bellcore.com> <136212@sun.Eng.Sun.COM> Sender: vjs@rhyolite.wpd.sgi.com Organization: Silicon Graphics, Inc., Mountain View, CA Lines: 44 In article <136212@sun.Eng.Sun.COM>, pugs@whitsun.Sun.COM (Tom Lyon) writes: > > My belief is that PostScript makes a pretty good intermediate language - we > just haven't figured out what the high level language should look like. Could you comment about the use of PostScript in file systems in view of Sun's experience with PostScript in window managers, setting asside the marketing issues with respect to X? I am making the obvious inference that Sun must view NeWS as a disaster, if only because of the amount of code that is being put down the memory hole. Could you say why NeWS and NeFS will have differing fates, despite the evident parallels between X vs. NeWS and NFS or AFS vs. NeFS? History (simplistic, one-sided history for third parties): -Sun announces a new, open standard for window managers, using PostScript, -Silicon Graphics receives presentations from Sun, and is impressed by the same arguements about sending programs instead of data. -SGI hears presentations from Getty's et al about X. -Since high speed graphics prefer programs to pixels and raster ops, SGI is less impressed by X than by NeWS. -SGI decides to join the Sun NeWS bandwagon. -after enormous porting, debugging, and re-writing effort and pain, NeWS becames the default window manager on Silicon Graphics IRIS's. -the same never seems to happen at Sun (the default, I wouldn't know about the pain). -X wins in the market, for various reasons. -Sun supports X vigorously and completely forgets NeWS. Summary: The idea is interesting. The implementation, particularly using PostScript, is less compelling for technical and business reasons. Disclaimer: NeWS will be the default in the next SGI release. Please do not understand anything here as an announcement--that's not my department. Moral: Avoid cute, mixed-case acronyms. Vernon Schryver vjs@sgi.com From mimsy!haven!aplcen!uunet!intercon!news Fri Jun 1 17:05:22 EDT 1990 Article 1037 of comp.protocols.nfs: Path: mimsy!haven!aplcen!uunet!intercon!news >From: amanda@mermaid.intercon.com (Amanda Walker) Newsgroups: comp.protocols.nfs Subject: Re: NeFS protocol Message-ID: <265DFAD2.5818@intercon.com> Date: 26 May 90 03:41:06 GMT References: <1990May24.034258.13625@Neon.Stanford.EDU> <3378@auspex.auspex.com> <1990May24.205149.6065@Neon.Stanford.EDU> <3385@auspex.auspex.com> <1990May25.234950.1465@Neon.Stanford.EDU> Sender: usenet@intercon.com (USENET The Magnificent) Reply-To: amanda@mermaid.intercon.com (Amanda Walker) Organization: InterCon Systems Corporation, Herndon, VA Lines: 27 In article <1990May25.234950.1465@Neon.Stanford.EDU>, pallas@Neon.Stanford.EDU (Joe Pallas) writes: > Now you may call those invocations programs, but they're really just RPCs. Yes and no. They are RPCs in the sense that any client/server transaction is an RPC, but the important difference between NeWS & NeFS and, say, X & NFS is that the RPC is defined by the client, on the fly, to suit the client's needs, not defined in advance by someone who has to try and figure out what clients will want. Let me take a presently hypothetical example: a file service client for my favorite machine, the Apple Macintosh. The biggest problem with doing this under NFS is that, despite a reasonable correspondence between the file systems themselves, the *operations* performable on a file system vary quite a bit between the Mac OS and NFS, thus requiring a ridiculous amount of either network traffic or client-side caching in order to get acceptable performance. With NeFS, the client can blort over some code that tells the server how to implement those operations that the client is going to want to invoke. Flexibility wins. This is probably even more true for file service than for display service... $.02,-- Amanda Walker, InterCon Systems Corporation -- "Go not to the elves for counsel, for they will say both no and yes." --J.R.R. Tolkien, The Lord of the Rings From mimsy!haven!aplcen!uunet!intercon!news Fri Jun 1 17:05:41 EDT 1990 Article 1038 of comp.protocols.nfs: Path: mimsy!haven!aplcen!uunet!intercon!news >From: amanda@mermaid.intercon.com (Amanda Walker) Newsgroups: comp.protocols.nfs Subject: Re: NeFS protocol Message-ID: <265DFDA9.58A5@intercon.com> Date: 26 May 90 03:53:12 GMT Sender: usenet@intercon.com (USENET The Magnificent) Reply-To: amanda@mermaid.intercon.com (Amanda Walker) Organization: InterCon Systems Corporation, Herndon, VA Lines: 16 OK. I've just FTP'd over the NeFS draft spec, and I am impressed. When I read the spec for NFS v2 (and XDR and RPC), my principal reaction was something along the lines of "Bleah--at least it seems to work, but I'm glad I don't have to deal with it." After reading through the NeFS draft, my principal reaction is, "OK, how long until they finalize it so that people can implement it?" NeFS gets my vote. -- Amanda Walker, InterCon Systems Corporation -- "Go not to the elves for counsel, for they will say both no and yes." --J.R.R. Tolkien, The Lord of the Rings From mimsy!haven!aplcen!samsung!cs.utexas.edu!uwm.edu!bionet!agate!shelby!neon!pallas Fri Jun 1 17:06:16 EDT 1990 Article 1041 of comp.protocols.nfs: Path: mimsy!haven!aplcen!samsung!cs.utexas.edu!uwm.edu!bionet!agate!shelby!neon!pallas >From: pallas@Neon.Stanford.EDU (Joe Pallas) Newsgroups: comp.protocols.nfs Subject: Re: NeFS protocol Message-ID: <1990May26.213221.15248@Neon.Stanford.EDU> Date: 26 May 90 21:32:21 GMT References: <1990May24.034258.13625@Neon.Stanford.EDU> <3378@auspex.auspex.com> <1990May24.205149.6065@Neon.Stanford.EDU> <3385@auspex.auspex.com> <1990May25.234950.1465@Neon.Stanford.EDU> <265DFAD2.5818@intercon.com> Organization: Computer Science Department, Stanford University Lines: 20 In article <265DFAD2.5818@intercon.com> amanda@mermaid.intercon.com (Amanda Walker) writes: >They are RPCs in the sense that any client/server transaction >is an RPC, but the important difference between NeWS & NeFS and, say, X & >NFS is that the RPC is defined by the client, on the fly, to suit the >client's needs, not defined in advance by someone who has to try and figure >out what clients will want. We have no disagreement here. My point is that, for Amanda's presently-hypothetical Macintosh NeFS client, the code which gets dynamically loaded into the server to define the Mac-appropriate RPC interface (things like lookup_file_ignoring_case, e.g.) will be written by humans, not programs. NeFS clients don't write code, they invoke code written by NeFS client implementors. And filesystem code will be even more complicated than graphics code, which is hard enough for humans to read and write in PostScript. joe From mimsy!haven!ames!think!zaphod.mps.ohio-state.edu!mips!sgi!vjs@rhyolite.wpd.sgi.com Fri Jun 1 17:08:54 EDT 1990 Article 1047 of comp.protocols.nfs: Path: mimsy!haven!ames!think!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 From mimsy!haven!purdue!tut.cis.ohio-state.edu!snorkelwacker!apple!portal!cup.portal.com!thinman Fri Jun 1 17:09:35 EDT 1990 Article 1048 of comp.protocols.nfs: Path: mimsy!haven!purdue!tut.cis.ohio-state.edu!snorkelwacker!apple!portal!cup.portal.com!thinman >From: thinman@cup.portal.com (Lance C Norskog) Newsgroups: comp.protocols.nfs Subject: Re: NeFS protocol Message-ID: <30275@cup.portal.com> Date: 28 May 90 21:41:31 GMT References: <1990May24.034258.13625@Neon.Stanford.EDU> <3378@auspex.auspex.com> <265DFAD2.5818@intercon.com> <61077@sgi.sgi.com> Distribution: usa Organization: The Portal System (TM) Lines: 16 It seems to me that the problem of sending a machine-independent program to a target machine for execution is intimately tied in with the problem of distributing application software in a machine-independent format. What OSF terms ANDF, or Architecture-Neutral Distribution Format. The quickest road to success is to hack GNU CC and C++ to compile to an ASN.1 format pseudo-assembler (called MIX, see Knuth's 3-volume opus) and ship that over the network, and on distribution tapes. The more high-level this MIX language (probably an object-oriented stack language) the faster compilation will be, and an interpreter/debugger will give a very nice development environment. The interpreter would include a full POSIX library, with optional run-time checking. Lance Norskog Sales Engineer Streamlined Networks From mimsy!tank!ux1.cso.uiuc.edu!brutus.cs.uiuc.edu!apple!rutgers!bellcore!messy!mo Fri Jun 1 17:10:28 EDT 1990 Article 1051 of comp.protocols.nfs: Path: mimsy!tank!ux1.cso.uiuc.edu!brutus.cs.uiuc.edu!apple!rutgers!bellcore!messy!mo >From: mo@messy.bellcore.com (Michael O'Dell) Newsgroups: comp.protocols.nfs Subject: Re: Writing Postscript code.... Message-ID: <23683@bellcore.bellcore.com> Date: 29 May 90 16:16:55 GMT Sender: news@bellcore.bellcore.com Reply-To: mo@messy.UUCP (Michael O'Dell) Organization: Center for Chaotic Repeatabilty Lines: 21 If the concerns about Postscript is that is is hard to write en masse, then having a C compiler which generates Postscript should alleviate a lot of those concerns (the meta-discussion of whether C is a programming language as well isn't appropriate for this group, and is moot as well). Further, if one looks closely at the existing NFS protocol and the NeFS built-ins, one will discover that it takes very little Postscript to implement most of what you really want to do. By all means, a certain amount of reason should prevail, like: I would not recommened an attempt to implement a database system in Postscript so it can be downloaded to the server!!! But by the same token, I have read (but admittedly not written much) NeWS code done with the Class system, and it certainly doesn't read as awful as some would imply. Have people been badly burned and are speaking from hard-won experience here? -Mike From mimsy!haven!ames!think!samsung!uunet!mcsun!ukc!icdoc!qmw-cs!liam Fri Jun 1 17:11:27 EDT 1990 Article 1052 of comp.protocols.nfs: Path: mimsy!haven!ames!think!samsung!uunet!mcsun!ukc!icdoc!qmw-cs!liam >From: liam@cs.qmw.ac.uk (William Roberts) Newsgroups: comp.protocols.nfs Subject: Re: NeFS protocol Message-ID: <2284@sequent.cs.qmw.ac.uk> Date: 29 May 90 09:06:46 GMT References: <1990May24.034258.13625@Neon.Stanford.EDU> <3378@auspex.auspex.com> <1990May24.205149.6065@Neon.Stanford.EDU> <3385@auspex.auspex.com> <1990May25.234950.1465@Neon.Stanford.EDU> <265DFAD2.5818@intercon.com> Organization: Computer Science Dept, QMW, University of London, UK. Lines: 52 In <265DFAD2.5818@intercon.com> amanda@mermaid.intercon.com (Amanda Walker) writes: >Let me take a presently hypothetical example: a file service client for >my favorite machine, the Apple Macintosh. The biggest problem with doing >this under NFS is that, despite a reasonable correspondence between the file >systems themselves, the *operations* performable on a file system vary quite >a bit between the Mac OS and NFS, thus requiring a ridiculous amount of either >network traffic or client-side caching in order to get acceptable performance. >With NeFS, the client can blort over some code that tells the server how >to implement those operations that the client is going to want to invoke. >Flexibility wins. This is probably even more true for file service than >for display service... The NeFS spec is quite clearly written as a slight generalisation over supporting a couple of slightly non-UNIX file systems. It doesn't go anywhere near supporting significantly different systems such as the Macintosh ("You mean each file has two parts, plus comments?") even though the polymorphic nature of PostScript would make it easy to allow things like arrays or dictionaries of filehandles rather than just single ones to be returned from open (for example). Flexibility is good, but NeFS seems to me to be all wrong. It dismisses the low-level network stuff with some hand waving, and it just feels like an insane way to go about something which needs to provide very high performance. I loved PostScript and was very fond of NeWS until it needed bigger machinery that I have available: NeFS just doesn't gell at all. I suggest we forget NeFS immediately and look at some real work addressing real problems: anyone who hasn't read the Coda paper should look out a copy Coda: A Highly Available File System for a Distributed Environment M. Satyanarayanan, J.J. Kistler et al IEEE Transactions on Computers, 39(4), 447-459, April 1990 Did anyone notice how little connection there was between the list of "problems with NFS" and the proposed solution? -- William Roberts ARPA: liam@cs.qmw.ac.uk Queen Mary & Westfield College UUCP: liam@qmw-cs.UUCP Mile End Road AppleLink: UK0087 LONDON, E1 4NS, UK Tel: 071-975 5250 (Fax: 081-980 6533) From mimsy!tank!ncar!asuvax!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!tut.cis.ohio-state.edu!rutgers!bellcore!messy!mo Fri Jun 1 17:13:07 EDT 1990 Article 1054 of comp.protocols.nfs: Path: mimsy!tank!ncar!asuvax!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!tut.cis.ohio-state.edu!rutgers!bellcore!messy!mo >From: mo@messy.bellcore.com (Michael O'Dell) Newsgroups: comp.protocols.nfs Subject: Re: NeFS protocol Message-ID: <23707@bellcore.bellcore.com> Date: 30 May 90 02:23:35 GMT References: <1990May24.034258.13625@Neon.Stanford.EDU> <3378@auspex.auspex.com> <265DFAD2.5818@intercon.com> <61077@sgi.sgi.com> Sender: news@bellcore.bellcore.com Reply-To: mo@messy.UUCP (Michael O'Dell) Organization: Center for Chaotic Repeatabilty Lines: 14 What might well be called "Clark's Law" is that "As bandwidth goes to infinity, latency becomes a constant 30 milliseconds." This is the round-trip delay across the US on a 1 gigabit or faster fibre-optic network. You can't change that number unless you change the speed of light, so there is NOTHING you can do about latency except avoid round trips!!! The fact that some application can successfully beat the life out of a local ethernet cable is NOT a feature when considering *networks which scale with latency*, and in Clark's view, and mine, them's the future of networking. Everthing else is essentially a multiprocessor by comparison. -Mike From mimsy!tank!ux1.cso.uiuc.edu!iuvax!rutgers!bellcore!messy!mo Fri Jun 1 17:13:32 EDT 1990 Article 1055 of comp.protocols.nfs: Path: mimsy!tank!ux1.cso.uiuc.edu!iuvax!rutgers!bellcore!messy!mo >From: mo@messy.bellcore.com (Michael O'Dell) Newsgroups: comp.protocols.nfs Subject: Re: ANDF?????????????????????? Message-ID: <23708@bellcore.bellcore.com> Date: 30 May 90 02:26:37 GMT References: <1990May24.034258.13625@Neon.Stanford.EDU> <3378@auspex.auspex.com> <265DFAD2.5818@intercon.com> <61077@sgi.sgi.com> <30275@cup.portal.com> Sender: news@bellcore.bellcore.com Reply-To: mo@messy.UUCP (Michael O'Dell) Distribution: usa Organization: Center for Chaotic Repeatabilty Lines: 5 The simplest solution is to just use the byte-coded postscript format proposed in the document and now being supported for lots of things at Sun (like boot roms). Let's just say that I wouldn't bet ANYTHING on ANDF. -Mike From mimsy!haven!uflorida!mailrus!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!sdd.hp.com!ucsd!ames!eos!shelby!neon!pallas Fri Jun 1 17:14:17 EDT 1990 Article 1056 of comp.protocols.nfs: Path: mimsy!haven!uflorida!mailrus!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!sdd.hp.com!ucsd!ames!eos!shelby!neon!pallas >From: pallas@Neon.Stanford.EDU (Joe Pallas) Newsgroups: comp.protocols.nfs Subject: Re: Writing Postscript code.... Message-ID: <1990May30.030703.462@Neon.Stanford.EDU> Date: 30 May 90 03:07:03 GMT References: <23683@bellcore.bellcore.com> Organization: Computer Science Department, Stanford University Lines: 19 In <23683@bellcore.bellcore.com> mo@messy.bellcore.com (Michael O'Dell) writes: >But by the same token, I have read (but admittedly not >written much) NeWS code done with the Class system, and >it certainly doesn't read as awful as some would imply. The NeWS Class system is best described as an example of an object-oriented language implemented in PostScript. Granted, it is an embedded implementation, so all of PostScript is exposed to the programmer. But its very existence is evidence of PostScript's inadequacy as a programming language. >Have people been badly burned and are speaking from hard-won >experience here? I know I have and am. I don't know about anyone else. joe From mimsy!haven!aplcen!samsung!usc!apple!voder!wlbr!awds26!mh Fri Jun 1 17:14:58 EDT 1990 Article 1057 of comp.protocols.nfs: Path: mimsy!haven!aplcen!samsung!usc!apple!voder!wlbr!awds26!mh >From: mh@awds26.imsd.contel.com (Mike Hoegeman) Newsgroups: comp.protocols.nfs Subject: Re: Writing Postscript code.... Message-ID: <53478@wlbr.IMSD.CONTEL.COM> Date: 30 May 90 19:35:23 GMT References: <23683@bellcore.bellcore.com> <1990May30.030703.462@Neon.Stanford.EDU> Sender: news@wlbr.IMSD.CONTEL.COM Reply-To: mh@awds26.UUCP (Mike Hoegeman) Organization: Contel FSD, Westlake Village, CA Lines: 29 In article <1990May30.030703.462@Neon.Stanford.EDU> pallas@Neon.Stanford.EDU (Joe Pallas) writes: > >The NeWS Class system is best described as an example of an >object-oriented language implemented in PostScript. Granted, it is an >embedded implementation, so all of PostScript is exposed to the >programmer. But its very existence is evidence of PostScript's >inadequacy as a programming language. > Well... you can make this rather flippant comment about almost any programming language. For example: "The very existence of the C standard library is evidence of C's inadequacy as a programming language." Which is a pretty ridiculous statement. I've used PostScript quite a bit (probably more than most of the PostScript flamers in previous postings) and i find it similar to lisp in ease of use , maintainablilty, etc.. >>Have people been badly burned and are speaking from hard-won >>experience here? > >I know I have and am. I don't know about anyone else. How have you been burned? This is, for the most part, genuine curiousity. I'd be interested in hearing something more specific. I don't have an opinion on NeFS one way or the other yet but this "I don't like PostScript, it's icky" commentary is non-informative at best. From mimsy!haven!aplcen!samsung!usc!apple!decwrl!sgi!vjs@rhyolite.wpd.sgi.com Fri Jun 1 17:16:50 EDT 1990 Article 1058 of comp.protocols.nfs: Path: mimsy!haven!aplcen!samsung!usc!apple!decwrl!sgi!vjs@rhyolite.wpd.sgi.com >From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) Newsgroups: comp.protocols.nfs Subject: Re: NeFS protocol Summary: latency==latency Message-ID: <61183@sgi.sgi.com> Date: 30 May 90 06:44:04 GMT References: <1990May24.034258.13625@Neon.Stanford.EDU> <3378@auspex.auspex.com> <23707@bellcore.bellcore.com> Sender: vjs@rhyolite.wpd.sgi.com Organization: Silicon Graphics, Inc., Mountain View, CA Lines: 47 In article <23707@bellcore.bellcore.com>, mo@messy.bellcore.com (Michael O'Dell) writes: > What might well be called "Clark's Law" is that "As bandwidth > goes to infinity, latency becomes a constant 30 milliseconds." > This is the round-trip delay across the US on a 1 gigabit or faster > fibre-optic network. You can't change that number unless you > change the speed of light, so there is NOTHING you can do about > latency except avoid round trips!!! > > The fact that some application can successfully beat the life out > of a local ethernet cable is NOT a feature when considering > *networks which scale with latency*, and in Clark's view, > and mine, them's the future of networking. Everthing else > is essentially a multiprocessor by comparison. > -Mike I am apologize for not being clear. I claim doing 20,000 "RPC's" per second over ethernet (i.e. 50 microsecond/call) is in some sense equivalent to doing a more familiar number (500/sec?) over a "high latency" medium such as cross-country fiber. In neither case is there time for one round trip per call. One round trip/call at 20,000 calls/sec comes out to 25 usec/packet. Isn't the minimum packet time, including preamble, something like 60.8 usec on 10MHz ethernet? Instead of remote-file-system-programming-languages, some cheating seems more to the point. Obviously, to get 20,000 "RPC's"/sec, not to mention the 1,000,000/sec that we would like, it was necessary to cheat. Obviously, you can't let the application, whether it is the upper layers of the file system or a graphics application, catch you cheating. You can get impressive preformance gains many places by cheating. The Sun use of the directory bit for client cache control is effective chicanery. The Silicon Graphics "private" NFS mount option is, IMH(&biased)O, even better. Some of the newer network file systems show signs of the right kind of cheating. Please note that 30 msec latency is not very bad. It permits >=15 round trips/second. An NFS rsize/wsize of 64K would in principle give 1MB/sec of data thru NFS, 5-10 times most current NFS implements. The big deal with GByte (not Gbit) fiber is not the latency, but the bandwidth*latency product. Having MBytes in flight stresses lots of interesting things. Vernon Schryver vjs@sgi.com From mimsy!haven!aplcen!uunet!snorkelwacker!bloom-beacon!ftp!jbvb Fri Jun 1 17:17:24 EDT 1990 Article 1059 of comp.protocols.nfs: Path: mimsy!haven!aplcen!uunet!snorkelwacker!bloom-beacon!ftp!jbvb >From: jbvb@ftp.COM (James Van Bokkelen) Newsgroups: comp.protocols.nfs Subject: Re: NeFS protocol Summary: Did the draft you saw still use 'long' seconds since 1-Jan-70? Message-ID: <1015@ftp.COM> Date: 30 May 90 19:08:24 GMT References: <265DFDA9.58A5@intercon.com> Organization: FTP Software Inc., Wakefield, MA Lines: 17 In article <265DFDA9.58A5@intercon.com>, amanda@mermaid.intercon.com (Amanda Walker) writes: > After reading through the NeFS draft, my principal reaction is, "OK, how > long until they finalize it so that people can implement it?" I read the draft of 12-Feb-90, and saw various levels of precision (file size of 64 bits, time resolution to the nanosecond) that might be looked on as overkill, but they stuck with 32 bits (unsigned, this time) of seconds since 1-Jan-1970 as the low-resolution component of the time format. One or two more bits would probably suffice for everything except interstellar probes and nuclear waste dump monitoring systems, but I wouldn't design anything of this potential scope to expire in 2106 CE. -- James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901 From mimsy!haven!aplcen!samsung!zaphod.mps.ohio-state.edu!tut.cis.ohio-state.edu!mailrus!ames!eos!shelby!neon!pallas Fri Jun 1 17:18:46 EDT 1990 Article 1063 of comp.protocols.nfs: Path: mimsy!haven!aplcen!samsung!zaphod.mps.ohio-state.edu!tut.cis.ohio-state.edu!mailrus!ames!eos!shelby!neon!pallas >From: pallas@Neon.Stanford.EDU (Joe Pallas) Newsgroups: comp.protocols.nfs Subject: Re: Writing Postscript code.... Message-ID: <1990May31.215127.15764@Neon.Stanford.EDU> Date: 31 May 90 21:51:27 GMT References: <23683@bellcore.bellcore.com> <1990May30.030703.462@Neon.Stanford.EDU> <53478@wlbr.IMSD.CONTEL.COM> Organization: Computer Science Department, Stanford University Lines: 40 In <53478@wlbr.IMSD.CONTEL.COM> mh@awds26.imsd.contel.com (Mike Hoegeman) writes: [quote of my saying the NeWS Class system is evidence of PostScript's inadequacy] >Well... you can make this rather flippant comment about almost any programming >language. For example: > "The very existence of the C standard library is evidence of C's > inadequacy as a programming language." >Which is a pretty ridiculous statement. Yes, I agree---because using standard library does not change the fundamental model of computation the way the NeWS objects-in-PostScript system does. The fundamental operation in the NeWS class system is "send message", which is not a PostScript operation. The fundamental operation in the use of a C library is "call function", which is a C operation. But this is not worth arguing over. >How have you been burned? This is, for the most part, genuine >curiousity. I'd be interested in hearing something more specific. I've been burned by dynamic binding, which makes it practically impossible to write recursive procedures with named own variables. I've been burned by stack overflow/underflow because some procedure didn't leave the stack the way some other procedure expected. I've been burned by STATIC binding, because Adobe encouraged people to use the "bind" operator, which improves performance by completely changing the semantics of the language. I've also been burned by the machine-dependent limit on the length of an executable array literal, when I had some code being generated by a program. All of this is just the language, excluding the times I've been burned by machine-dependent graphics operations. joe From mimsy!haven!ames!elroy.jpl.nasa.gov!david Mon Jun 4 07:28:25 EDT 1990 Article 1065 of comp.protocols.nfs: Path: mimsy!haven!ames!elroy.jpl.nasa.gov!david >From: david@elroy.jpl.nasa.gov (David Robinson) Newsgroups: comp.protocols.nfs Subject: NeFS overkill? Message-ID: <1990Jun1.231507.13779@elroy.jpl.nasa.gov> Date: 1 Jun 90 23:15:07 GMT Sender: david@elroy.jpl.nasa.gov (David Robinson) Organization: Image Analysis Systems Grp, JPL Lines: 36 Having read the NeFS specification I consider it an interesting approach to creating a networked filesystem between heterogenous operating systems. But I wonder how useful it will be in the real world. Looking at the current implementations of NFS clients the vast majority use some sort of virtual filesystem or filesystem switch to provide a mostly transparent access to remote files with minimal changes to user level code. For example: Sun VFS, AT&T FSS, PC-NFS redirectors, VMS ACPs, and others. Few actually bury network specific code into user level applications. If you examine each of the methods currently used, most gain very little from using an interpreter on the server. The example in the draft of implementing the Unix "du" facility is a nice elegant example of NeFS. Unfortunately without a completely new, high level system interface, all the underlying OS and NeFS are going to see is a bunch of readdir and getattr function calls. The interpretive nature of a server gains very little functionality. In addressing the hetrogenous nature, PostScript dictionaries are very nice for providing the ability to have extensible and varying attributes between systems. But this can almost as easily be handled with extensible data structures without the overhead of an interpreter. With the exception of a minority of machines such as LISP machines there is a great lack of technology to take advantage NeFS while preserving the transparency of user level code. NeFS is an interesting technology but is it appropriate to solve the problems of the existing NFS? -David -- David Robinson david@elroy.jpl.nasa.gov {decwrl,usc,ames}!elroy!david Disclaimer: No one listens to me anyway! "Once a new technology rolls over you, if you're not part of the steamroller, you're part of the road." - Stewart Brand From mimsy!haven!aplcen!uakari.primate.wisc.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!brutus.cs.uiuc.edu!apple!portal!cup.portal.com!thinman Mon Jun 4 07:29:02 EDT 1990 Article 1066 of comp.protocols.nfs: Path: mimsy!haven!aplcen!uakari.primate.wisc.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!brutus.cs.uiuc.edu!apple!portal!cup.portal.com!thinman >From: thinman@cup.portal.com (Lance C Norskog) Newsgroups: comp.protocols.nfs Subject: More comments on NeFS Message-ID: <30431@cup.portal.com> Date: 2 Jun 90 00:16:51 GMT References: <23683@bellcore.bellcore.com> <1990May30.030703.462@Neon.Stanford.EDU> <53478@wlbr.IMSD.CONTEL.COM> <1990May31.215127.15764@Neon.Stanford.EDU> Organization: The Portal System (TM) Lines: 10 NeFS is an attempt at a standard for throwing arbitrary programs at distant machines for execution. The format of the programs should be compilable and reasonably parallelizable, and PostScript is neither. RISC was the last easy trick for building fast machines, and multi-processing is the current one. An interpreted programming language might have been right for the 1980-vintage CP/M world, but not now. Lance p.s. I didn't call it PostSh*t, but I sure was tempted. From mimsy!haven!decuac!decwrl!elroy.jpl.nasa.gov!ames!sun-barr!newstop!sun!terra.Eng.Sun.COM!brent Mon Jun 4 07:30:33 EDT 1990 Article 1067 of comp.protocols.nfs: Path: mimsy!haven!decuac!decwrl!elroy.jpl.nasa.gov!ames!sun-barr!newstop!sun!terra.Eng.Sun.COM!brent >From: brent@terra.Eng.Sun.COM (Brent Callaghan) Newsgroups: comp.protocols.nfs Subject: Re: NeFS protocol Message-ID: <136362@sun.Eng.Sun.COM> Date: 30 May 90 00:32:20 GMT References: <1990May24.034258.13625@Neon.Stanford.EDU> <3378@auspex.auspex.com> <2284@sequent.cs.qmw.ac.uk> Sender: news@sun.Eng.Sun.COM Lines: 56 In article <2284@sequent.cs.qmw.ac.uk>, liam@cs.qmw.ac.uk (William Roberts) writes: > The NeFS spec is quite clearly written as a slight > generalisation over supporting a couple of slightly non-UNIX > file systems. It doesn't go anywhere near supporting > significantly different systems such as the Macintosh ("You > mean each file has two parts, plus comments?") even though the > polymorphic nature of PostScript would make it easy to allow > things like arrays or dictionaries of filehandles rather than > just single ones to be returned from open (for example). The NeFS protocol goes a long way toward making Mac implementations more efficient. File attributes are represented as a dictionary - name/value pairs. The resource and finder forks of a Mac file could be represented as attributes of the data fork. Alternatively, if the server is not a Mac server and is not capable of supporting arbitrary attributes - we can fall back on Applesingle or AppleDouble representations. Either way, the protocol allows a Mac client to construct a single NeFS request to do what it wants. Consider the NFS requests required of a Mac client: to open a folder on the Mac desktop requires a READDIR to enumerate the files, then a LOOKUP on *each* name to obtain its attributes, followed by a READ on some of the files to get the icon. > Flexibility is good, but NeFS seems to me to be all wrong. It > dismisses the low-level network stuff with some hand waving, The draft spec for NeFS is deliberately vague about "low-level network stuff". There's nothing to be gained by spelling out in detail what transport is going to convey requests between client and server at this stage in the design. Currently, the prototype is built on RPC/XDR like NFS because that's what we know best. Eventually there will be a document that defines the protocol as expressed by RPC/XDR. > and it just feels like an insane way to go about something > which needs to provide very high performance. Why insane ? If we're talking client or server CPU there isn't really a lot of difference between NFS and NeFS. The client just transmits "canned" requests - these do not have to be generated on the fly. Existing NFS servers already employ an "interpreter" of sorts: the server currently executes one "operation" per request as defined by the NFS procedure number. The NeFS protocol just allows the client to string a bunch of operations together. The overhead in executing these operations is extremely small; it's just tiny drops of glue between vastly more expensive I/O operations. Remember: the drops of glue have the potential to eliminate hugely expensive over-the-wire operations. -- Made in New Zealand --> Brent Callaghan @ Sun Microsystems uucp: sun!bcallaghan phone: (415) 336 1051 From mimsy!haven!decuac!decwrl!shelby!eos!ames!sun-barr!newstop!sun!terra.Eng.Sun.COM!brent Mon Jun 4 07:31:07 EDT 1990 Article 1069 of comp.protocols.nfs: Path: mimsy!haven!decuac!decwrl!shelby!eos!ames!sun-barr!newstop!sun!terra.Eng.Sun.COM!brent >From: brent@terra.Eng.Sun.COM (Brent Callaghan) Newsgroups: comp.protocols.nfs Subject: Re: NeFS protocol Message-ID: <136422@sun.Eng.Sun.COM> Date: 31 May 90 01:09:50 GMT References: <265DFDA9.58A5@intercon.com> <1015@ftp.COM> Sender: news@sun.Eng.Sun.COM Lines: 22 In article <1015@ftp.COM>, jbvb@ftp.COM (James Van Bokkelen) writes: > I read the draft of 12-Feb-90, and saw various levels of precision > (file size of 64 bits, time resolution to the nanosecond) that might > be looked on as overkill, but they stuck with 32 bits (unsigned, this > time) of seconds since 1-Jan-1970 as the low-resolution component of > the time format. One or two more bits would probably suffice for > everything except interstellar probes and nuclear waste dump > monitoring systems, but I wouldn't design anything of this potential > scope to expire in 2106 CE. Nanosecond resolution is required by Svr4. I don't know of any server that currently requires this resolution - but you never know... I'd be very happy if this protocol outlives me - let alone my grandchildren. Perhaps by 2106 we will almost be converted over to OSI protocols :-) -- Made in New Zealand --> Brent Callaghan @ Sun Microsystems uucp: sun!bcallaghan phone: (415) 336 1051 From mimsy!haven!purdue!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!lth.se!newsuser Mon Jun 4 07:31:30 EDT 1990 Article 1072 of comp.protocols.nfs: Path: mimsy!haven!purdue!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!lth.se!newsuser >From: Dan@dna.lth.se (Dan Oscarsson) Newsgroups: comp.protocols.nfs Subject: Re: Writing Postscript code.... Message-ID: <1990Jun3.124917.11694@lth.se> Date: 3 Jun 90 12:49:17 GMT References: <53478@wlbr.IMSD.CONTEL.COM> <506@cvbnetPrime.COM> Sender: newsuser@lth.se (LTH network news server) Organization: Computer Science, Lund Institute of Technology, Sweden Lines: 20 In article <506@cvbnetPrime.COM> aperez@cvbnet.UUCP (Arturo Perez x6739) writes: > >Anyway, all I know about Postscript is that it's ugly and proprietary (not >necessarily the same thing :-). > >What makes Postscript so hard (or easy) to program in? And why should we even >want to write filesystems in a language designed for page description? > >Why isn't someone proposing a language designed for something a little more >general? For example, how about Smalltalk? > >Hey, just 'cause Postscript is out there doesn't mean we have to use it. We >could probably use any interpretable language, Lisp, Forth, or even Perl! > PostScript is nice and easy to program in. Smalltalk, Lisp, Forth are ugly. I would never think of using Smalltalk or Lisp for a NeFS or NeWS server. Dan