Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!umich!yale!mintaka!bloom-beacon!eru!luth!sunic!mcsun!ukc!icdoc!qmw-cs!liam
From: liam@cs.qmw.ac.uk (William Roberts)
Newsgroups: comp.protocols.nfs
Subject: Re: NeFS -- where is the multiplexer?
Keywords: NeFS, NFS
Message-ID: <2494@sequent.cs.qmw.ac.uk>
Date: 10 Jul 90 12:09:08 GMT
References: <1086@cluster.cs.su.oz> <138584@sun.Eng.Sun.COM>
Organization: Computer Science Dept, QMW, University of London, UK.
Lines: 55

In <138584@sun.Eng.Sun.COM> brent@terra.Eng.Sun.COM (Brent Callaghan) writes:

>For the first cut at this protocol we're not proposing anything very
>radical when it comes to NeFS "processes".  Indeed, there's no process
>support at all (c.f. NeWS).  The client typically sends a request and

In case anyone is confused, NeWS *does* have processes but NeFS doesn't

>blocks while the request is executed on the server.  This isn't any
>different from the RPC model that NFS uses.  A request will run just
>as long as the server wants it to i.e. until it completes or it runs
>out of resources: memory or execution quota.

>It's possible that the a client (probably not a Unix one) could construct
>a request that could take a long time e.g. copy a big file on the server
>or walk the file tree doing a "find".  The client has no way of knowing
>how long the request will take or indeed whether the request was received
>by the server at all (assuming something like UDP is used as the transport).
>The protocol already has the hooks to address these problems.  There's
>no reason why a request should not be able to generate multiple responses.
>A request could be constructed that sends a "check-in" response back to
>the client when it gets to the server and begins execution.  It could
>also generate progress reports to the client during execution at
>intervals smaller than the client's timeout.

Irrelevant - if I ask the server to calculate pi to a million
decimal paces and then read a block, I should expect it to take
a long time. The people who are in trouble are the other
clients expecting to see the NeFS server handle the simple
request they sent it less than a second ago.

>It gets tricky if the client wants to cancel a request that's executing
>on the server.  For instance, a find executing on the server may send
>a response back to the client for each filesystem object as it is located.
>If the client receives a response that indicates that there's no point
>in further searching - how does it refer to the request in progress ?
>Something as simple as a "getpid" and "kill" ops could do the trick.

>Several have suggested adding a facility that lets a request fork
>multiple processes on the server where appropriate e.g. a search
>of a filesystem tree.  This is a relatively rare filesystem operation.
>The extra complexity doesn't justify itself (KISS).

Sorry but that won't do. If NeFS isn't multi-threading requests
then it really is a totally stupid suggestion and not worth
wasting time on.

When will you people stop messing about and
work on a *real* improvement to NFS?
-- 

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)