Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!uunet!iconsys!mmm
From: mmm@iconsys.icon.com (Mark Muhlestein)
Newsgroups: comp.arch
Subject: Re: Incremental sync()s and using disk idle time
Message-ID: <1991Mar12.010155.3268@iconsys.icon.com>
Date: 12 Mar 91 01:01:55 GMT
References: <1991Mar7.115154.4820@hq.demos.su> <1991Mar8.142031.9098@bellcore.b <KINCH.91Mar9170121@no31sun.csd.uwo.ca>
Organization: Sanyo/Icon International, Inc., Orem, Utah
Lines: 52

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.
>
>I don't just mean what requests are satisified first (although this would 
>be one of its tasks) but one which also supports an abstract filesystem. 
>This would take out alot of logic from the kernel, it needn't spend time
>through namei() et al. let an intellegent controller do that. 
>
>Am I missing something important here, other than the fact that no operating
>system I am aware of has a concept of an abstract filesystem (except at 
>the user level). There is still some logic needed re virtual memory and 
>possible page-outs etc but I think it could work. Any comments?
>

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.

For one thing, some normally trivial things like lseek and updating times
on files become heavy-weight operations involving message passing to the
filesystem processor.  Also, very small reads and writes were extremely
inefficient compared to a normal unix implementation.  Another problem was
keeping the filesystem code in sync with new versions of the rest of the
kernel.  Enhancements and new features were relatively much more
difficult to implement.  For example, since the filesystem procecessor
handles all filesystem requests, it is necessary to teach it about NFS,
file system types, etc.  It goes far beyond just an "intelligent" controller.

We solved these problems using various techniques that relied on the fact
that the filesystem processor shared memory with the processor running the
rest of the kernel.  These techniques don't really make sense for, say,
a SCSI-based controller.

From my experience, a good SCSI controller with scatter-gather DMA capability
has about the right amount of intelligence.  It doesn't require a lot
of hand-holding to keep it going, and it gets the job done with a
minimum of hassling with low-level details like device geometry,
bad block management, or retries.
-- 

	Mark Muhlestein @ Sanyo/Icon

uunet!iconsys!mmm