mod-os@sdcsvax.uucp (01/14/87)
-- In article <2438@sdcsvax.UCSD.EDU> henry@utzoo.uucp writes: > >Alternatively, does it matter? It's all very well to say that your file >system is in a user-state server rather than in your kernel, but your users >are probably just as dependent on every little detail being right. To make >user-state servers more than an irrelevant implementation detail, the user >must be offered a choice of servers AND IT MUST BE EASY TO WRITE A SERVER! >Or at least, not impossibly hard. If writing a server is as touchy a job >as writing the equivalent inside the kernel, the wonderful flexibility will >get little use. > Amoeba has three user-space file servers: 1. A UNIX-like file server (actually the MINIX file server). 2. The FUSS file server, which is a research type file server with atomic commit (see 10th SOSP). 3. A dumb, but very fast file server. File servers are not something that every user can write, but I certainly want the flexibility of having various gurus and researchers being able to write new file servers whenever they want to. Writing a file server is a fair amount of work, but is not unreasonable for a Master's thesis. Andy Tanenbaum --
retrac@sdcsvax.UUCP (01/16/87)
-- In article <2438@sdcsvax.UCSD.EDU> henry@utzoo.uucp writes: >> >>Alternatively, does it matter? It's all very well to say that your file >>system is in a user-state server rather than in your kernel, but your users >>are probably just as dependent on every little detail being right. To make >>user-state servers more than an irrelevant implementation detail, the user >>must be offered a choice of servers AND IT MUST BE EASY TO WRITE A SERVER! >>Or at least, not impossibly hard. If writing a server is as touchy a job >>as writing the equivalent inside the kernel, the wonderful flexibility will >>get little use. >> > In article <2455@sdcsvax.UCSD.EDU> ast@botter.cs.vu.nl (Andy Tanenbaum) writes: >Amoeba has three user-space file servers: > [Description of three Amoeba fileservers here...] > >File servers are not something that every user can write, but I certainly >want the flexibility of having various gurus and researchers being able to >write new file servers whenever they want to. Writing a file server is >a fair amount of work, but is not unreasonable for a Master's thesis. > >Andy Tanenbaum >-- The situation is similar here at Rice in the Distributed System group where we run a version of the V operating system originally developed at Stanford University. In V, most services are provided by user level processes, including the file server. There is one file server which piggybacks on top of a UNIX machine as a UNIX process (can you say SLOW?). When we decided that we wanted better performance, but didn't want to abandon the UNIX one (for various reasons), we were able to write our own to run directly on a SUN-3. It isn't totally debugged yet, but runs *many* *many* times faster than the original. Thus, the fact that the file server was not a part of the kernel allowed us the flexibility we needed to write our own but keep the original. It wasn't an easy task (not something that the casual user would want to do), but the bulk of it was done by two senior graduate students over 2 to 3 months (I'm not one), with feedback and advice from other members of the group. I also certainly want the flexibility to write my own version of critical servers. In article <2455@sdcsvax.UCSD.EDU> darrell@sdcsvax.UCSD.EDU writes: >I guess the main reason I designed my distributed file >system in the kernel was to ensure that existing binaries >did not have to be recompiled to take advantage of remote >access. I don't think this is possible with user-level >servers, is it? If it is, could you please direct me to >technical information about how this is/was/could be done? >I would be very interested. Under V, the important server processes respond to messages sent to well known process group identifiers. As long as any new server process answers to requests to that group id, and provides the services requested, whether they are the original version or a new one is transparent to the user process. (This caused problems when the new fileserver was still fairly buggy - it'd accept the requests from unsuspecting processes, but then return garbage. The fix was to tell it to stop accepting requests not sent to it specifically, until the bug(s) were found). Several V papers describe how this works. John Carter --