Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!crackers!m2c!umvlsi!dime!dime.cs.umass.edu!moss
From: moss@cs.umass.edu (Eliot Moss)
Newsgroups: comp.protocols.nfs
Subject: Re: Incremental sync()s and using disk idle time
Message-ID: <MOSS.91Mar10102759@ibis.cs.umass.edu>
Date: 10 Mar 91 15:27:59 GMT
References: <28975@cs.yale.edu> <PCG.91Feb28195347@odin.cs.aber.ac.uk>
	<PCG.91Mar4210505@aberdb.cs.aber.ac.uk>
	<1991Mar5.223443.21187@ns.uoregon.edu>
	<1991Mar6.003008.9131@bellcore.bellcore.com>
	<1991Mar7.115154.4820@hq.demos.su> <1991Mar8.142031.9098@bellcore.b
Sender: news@dime.cs.umass.edu
Reply-To: moss@cs.umass.edu
Followup-To: comp.protocols.nfs
Organization: Dept of Comp and Info Sci, Univ of Mass (Amherst)
Lines: 37
In-reply-to: kinch@no31sun.csd.uwo.ca's message of 9 Mar 91 22:01:21 GMT

In article <KINCH.91Mar9170121@no31sun.csd.uwo.ca> kinch@no31sun.csd.uwo.ca (Dave Kinchlea) writes:

   In article <10773@dog.ee.lbl.gov> torek@elf.ee.lbl.gov (Chris Torek) writes:
      Sometimes I think we need a Coalition to Stamp Out `Smart' I/O Devices,

   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?

Yes, I think you are missing something important. To get good performance with
databases, object stores, and other I/O intensive applications, the
application needs much more control over I/O device usage, both in the sense
of space allocation (placement) and scheduling. Un*x systems have been very
poor in this area; traditional mainframe systems have typically done better.
In my opinion, the root of the difficulty is that Un*x is designed and tuned
for the behavior of certain kinds of time sharing usage, and does not provide
the features and policies needed for these other kinds of things. Moving all
the behavior off into a less controllable I/O device would seem to me to be a
step backwards.
--

		J. Eliot B. Moss, Assistant Professor
		Department of Computer and Information Science
		Lederle Graduate Research Center
		University of Massachusetts
		Amherst, MA  01003
		(413) 545-4206, 545-1249 (fax); Moss@cs.umass.edu