Xref: utzoo comp.protocols.nfs:1929 comp.arch:21396 Newsgroups: comp.protocols.nfs,comp.arch Path: utzoo!henry From: henry@zoo.toronto.edu (Henry Spencer) Subject: Re: Incremental sync()s and using disk idle time Message-ID: <1991Mar12.194704.17859@zoo.toronto.edu> Date: Tue, 12 Mar 1991 19:47:04 GMT References: <28975@cs.yale.edu> <10773@dog.ee.lbl.gov> <3236@crdos1.crd.ge.COM> Organization: U of Toronto Zoology In article <3236@crdos1.crd.ge.COM> davidsen@crdos1.crd.ge.com (bill davidsen) writes: >| Sometimes I think we need a Coalition to Stamp Out `Smart' I/O Devices, > There are cases when order is important, but as long as those rare >cases are satisfied, any smarts which improve performance as welcome on >my system. The trouble is, what if the "smarts" *don't* improve performance, on your workload? The only sensible place to put smarts is in host software, where it can be changed to match the workload and to keep up with new developments. "Smart" hardware almost always makes policy decisions, which is a mistake. The money spent on "smartening" the hardware is usually better spent on making the main CPU faster so that you can get the same performance with smart *software*... especially since a faster CPU is good for a lot of other things too. -- "But this *is* the simplified version | Henry Spencer @ U of Toronto Zoology for the general public." -S. Harris | henry@zoo.toronto.edu utzoo!henry