Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!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: <2510@sequent.cs.qmw.ac.uk> Date: 13 Jul 90 11:39:00 GMT References: <138779@sun.Eng.Sun.COM> Organization: Computer Science Dept, QMW, University of London, UK. Lines: 61 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)