Path: utzoo!news-server.csri.toronto.edu!rutgers!uwvax!shorty.cs.wisc.edu!dparter From: dparter@shorty.cs.wisc.edu (David Parter) Newsgroups: comp.arch Subject: Re: Incremental sync()s and using disk idle time Message-ID: <1991Mar12.201003.20623@spool.cs.wisc.edu> Date: 12 Mar 91 20:10:03 GMT References: <1991Mar8.142031.9098@bellcore.b <1991Mar12.010155.3268@iconsys.icon.com> Sender: news@spool.cs.wisc.edu (The News) Organization: University of Wisconsin CS Department Lines: 67 In article <1991Mar12.010155.3268@iconsys.icon.com> mmm@iconsys.icon.com (Mark Muhlestein) writes: >Dave Kinchlea, cs grad student at UWO writes: >> >>Actually I have been having quite the oposite thoughts lately. It seems to me >>that it would be highly advantagous (in the general case) to take all of >>the filesystem information out of the kernel and give it to the I/O controller. >At Sanyo/Icon we actually implemented this idea approximately five years >ago in our first Unix port. We used a dedicated 68020 with an expandable >cache (up to 128MB!) to run the filesystem code. > >It has worked reasonably well for us, but, in retrospect, I'm not at all >sure I would do it again. Although some things are a win, such as >being able to overlap relatively CPU-intensive functions such as namei() >with other processing, we discovered very soon that a naive approach >had several severe performance and maintenance problems. > > [interesting examples of flaws deleted] [Note: I keep saying "they" in the following section. We didn't have an "us" vs "them" situation, once we starting talking to each other about the project, the two groups worked well together]. At a place I used to work (before returning to school), I participated in discussions with a group that wanted to do just this (put the f/s code into a controller). However, the scheme had the following flaws (among others): * Since not everyone would have the integrated f/s and controller, the entire file system code would have to remain in the kernel as well, for those using traditional controllers. * For RFS and NFS, and least part of the file system code had to remain in the kernel * The proposed solution assumed 1) the performance bottlenecks were in the code that would be off-loaded and 2) either the dedicated processor (on the controller) could run the code faster than the existing (main) cpu, or there was something more useful that the main processor could be doing while the controller was running the file system code. None of these assumptions had been studied. The best implimentation (from a software point of view) would be to use the vnode switch (Sun's virtual file system layer) and implement the integrated system as a new file system type -- sort of running NFS over the bus, but not really (we wouldn't use UDP, we'd use the message-passing already in place for communicating with "smart" i/o devices). This wasn't quite what they had in mind, but that is because they didn't know about NFS (they were a hardware/firmware group, not part of the Unix group originally). In addition, it was proposed to run a stripped-down unix on the controller, so that the unix filesystem code would "just run" (thus gaining uniformity of operation and semantics, and keeping the code in lock-step with the kernel code with little software effort). They then pointed out that other i/o could be handled by this super-controller as well... the paper monster that evolved was an odd multiprocessor configuration: Two identical (or nearly identical) CPUs, one running user processes and and most of the kernel, the other running various parts of the i/o system (with some duplication, such as a buffer cache in both places, etc). A more general multiprocessor solution (where the additional cpu/s could be used either for I/O or computation) made more sense. --david -- david parter dparter@cs.wisc.edu