Xref: utzoo comp.protocols.nfs:1910 comp.arch:21332 Path: utzoo!utgpu!watserv1!ria!ria.ccs.uwo.ca!kinch From: kinch@no31sun.csd.uwo.ca (Dave Kinchlea) Newsgroups: comp.protocols.nfs,comp.arch Subject: Re: Incremental sync()s and using disk idle time Message-ID: Date: 9 Mar 91 22:01:21 GMT References: <28975@cs.yale.edu> <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@ria.ccs.uwo.ca Followup-To: comp.protocols.nfs Organization: Computer Science Dept., University of Western Ontarioqq Lines: 25 In-reply-to: torek@elf.ee.lbl.gov's message of 9 Mar 91 00:26:10 GMT 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, -- In-Real-Life: Chris Torek, Lawrence Berkeley Lab EE div (+1 415 486 5427) Berkeley, CA Domain: torek@ee.lbl.gov 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? cheers kinch Dave Kinchlea, cs grad student at UWO (thats in London Ontario)