bruce@cs.su.oz.au (07/08/90)
Under the NFS protocol, client requests can be handled by
a single NFS server running on the remote machine.
This single-threadedness is possible because of the simple nature of each supported
RPC operation, (and because of restrictions imposed by the mount
protocol) and the resultant fact that each RPC request is
known to be executable in "a short time" on the server.
(The popular use of multiple nfsd's (4?, 8?) is inspired by
considerations of efficiency rather than necessity.)
Typically, a heavily used NFS server will continue to
serve all clients fairly (but perhaps this is more by accident than
by design) due to the fairness implicit in the way that
the underlying protocol "passes up" incoming requests.
Moreover, clients can behave very simply in the face of missing
RPC replies -- they just assume that any outstanding calls have
been lost and retransmit them.
An NeFS server must provide an execution environment for each client
request rather than just provide access to a set of bounded procedure
calls, as is done by an NFS server.
This is necessary because of the generality of the Postscript
language -- it is possible to write and execute requests of unbounded
execution time.
We now start to see an NeFS server more as an operating system
than as a file server.
Under this view, each client request corresponds to a process.
Thus the structure of an NeFS server needs to be significantly more
complex -- or at least contain more arbitrary decisions -- than
an NFS server.
When we look at NeFS servers from this alternate perspective
questions arise.
How do I find out details about what NeFS "processes" are currently
running on the server?
How do I name one of these NeFS processes?
How do I kill (abort) such an NeFS process?
Does the Postcript language already support such primitives (or
was Postscript targeted at a uniprocessing environment)?
[These primitives don't appear to be mentioned in the NeFS document.]
What primitives are provided to allow NeFS processes to communicate
with each other? How about with the other "regular" processes
concurrently running on the remote machine but outside of the NeFS server(s)?
How about communication with processes back on the client machine?
How do I debug an NeFS process?
How are NeFS processes scheduled (e.g. what granularity of time-slicing)?
Can NeFS operations block in general? NFS operations can not block but
under NeFS both a precedent ("lock") and a mechanism (via suspension
of an NeFS process' execution) are provided.
Cheers,
bruce.
Bruce Janson
Basser Department of Computer Science
University of Sydney
Sydney, N.S.W., 2006
AUSTRALIA
Internet: bruce@basser.cs.su.oz.au
Telephone: +61-2-692-3264
Fax: +61-2-692-3838brent@terra.Eng.Sun.COM (Brent Callaghan) (07/10/90)
In article <1086@cluster.cs.su.oz>, bruce@cs.su.oz.au writes: > Under this view, each client request corresponds to a process. > Thus the structure of an NeFS server needs to be significantly more > complex -- or at least contain more arbitrary decisions -- than > an NFS server. > > When we look at NeFS servers from this alternate perspective > questions arise. > How do I find out details about what NeFS "processes" are currently > running on the server? > How do I name one of these NeFS processes? > How do I kill (abort) such an NeFS process? > Does the Postcript language already support such primitives (or > was Postscript targeted at a uniprocessing environment)? > [These primitives don't appear to be mentioned in the NeFS document.] > What primitives are provided to allow NeFS processes to communicate > with each other? How about with the other "regular" processes > concurrently running on the remote machine but outside of the NeFS server(s)? > How about communication with processes back on the client machine? > How do I debug an NeFS process? > How are NeFS processes scheduled (e.g. what granularity of time-slicing)? > Can NeFS operations block in general? NFS operations can not block but > under NeFS both a precedent ("lock") and a mechanism (via suspension > of an NeFS process' execution) are provided. 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 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. 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). -- Made in New Zealand --> Brent Callaghan @ Sun Microsystems uucp: sun!bcallaghan phone: (415) 336 1051
liam@cs.qmw.ac.uk (William Roberts) (07/10/90)
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)
amanda@mermaid.intercon.com (Amanda Walker) (07/12/90)
In article <2494@sequent.cs.qmw.ac.uk>, liam@cs.qmw.ac.uk (William Roberts) writes: > 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. Just because the 'language' is single-threaded doesn't mean that the server implementation is. The fact that one client connection will block on a long operation has nothing to do with other connections... -- Amanda Walker <amanda@intercon.com> InterCon Systems Corporation
brent@terra.Eng.Sun.COM (Brent Callaghan) (07/12/90)
> 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. This doesn't make sense. If you steal CPU cycles from your server it'll slow down client's requests not matter what protocol they're using to access the server's filesystem. > >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. I think you're confused here. There's nothing to prevent an NeFS server from being multi-threaded. It's completely up to the implementation. NFS servers typically run multiple threads via nfsd contexts. There's nothing to stop you having nefsd's too. The discussion was whether multiple threads should be visible to a NeFS request i.e. should a request be able to "fork" itself when it arrives at the server. -- Made in New Zealand --> Brent Callaghan @ Sun Microsystems uucp: sun!bcallaghan phone: (415) 336 1051
barmar@think.com (Barry Margolin) (07/12/90)
In article <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 >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. I think you're answering the wrong question. The issues isn't client processes but *server* processes. If a client sends an NeFS request that runs for a long time (or worse, contains an infinite loop), the server process will be unable to respond to other clients for the duration of that request. This is true with NFS as well, but NFS doesn't have any operations that can take a long time on the server, so clients can't really block each other out for long. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
liam@cs.qmw.ac.uk (William Roberts) (07/13/90)
In <138779@sun.Eng.Sun.COM> brent@terra.Eng.Sun.COM (Brent Callaghan) writes: >> 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. >This doesn't make sense. If you steal CPU cycles from your >server it'll slow down client's requests not matter what >protocol they're using to access the server's filesystem. But NeFS is precisely about stealing server cycles in order to avoid network traffic; if you are going to process information in the server (e.g. searching for things, stating a whole directories-worth of files etc) then you are going to eat its CPU cycles. >> >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. >I think you're confused here. There's nothing to prevent >an NeFS server from being multi-threaded. It's completely >up to the implementation. NFS servers typically run multiple >threads via nfsd contexts. There's nothing to stop you >having nefsd's too. The discussion was whether multiple >threads should be visible to a NeFS request i.e. should >a request be able to "fork" itself when it arrives at the >server. If you are going to support multiple threads within a single instance of the nefsd then you might as well offer this to the clients. If you are going to have multiple distinct nefsds in order to allow client requests to be processed in parallel then I agree that "fork" is making it more complicated. Aren't you leaving too much up to "the implementation" and "the networking layer"? If you want NeFS to work over datagram services as NFS does at present then you will need to have some language support for this, if only in the form of some standard way of finding out in an NeFS program about some aspects of the underlying network (e.g. is it reliable or not?). I still think that in terms of having a better NFS in the next year or so, you would be better implementing a named extensions mechanism similar to that used by X. This has the advantage that small extensions can be tried and ractical experiences folded into the grand NeFS redesign, rather than having to get all of the NeFS design right first time. -- 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)