Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!think.com!snorkelwacker.mit.edu!ira.uka.de!smurf!altger!doitcr!de.intel.com!intelhf!ichips!ichips!glew From: glew@pdx007.intel.com (Andy Glew) Newsgroups: comp.protocols.nfs Subject: Re: Incremental sync()s and using disk idle time Message-ID: Date: 14 Mar 91 09:34:18 GMT References: <28975@cs.yale.edu> <1991Mar12.202238.19586@zoo.toronto.edu> <3254@crdos1.crd.ge.COM> Sender: news@omews63.intel.com (News Account) Followup-To: comp.protocols.nfs Organization: Intel Corp., Hillsboro, Oregon Lines: 34 In-Reply-To: davidsen@crdos1.crd.ge.COM's message of 12 Mar 91 22:36:00 GMT >| That aside, the most probable result is that your big expensive main host >| CPU, which could undoubtedly run that code a lot faster, will spend all >| its time waiting for the dumb little I/O controller to run the filesystem. >| This is not a cost-effective use of hardware resources. > > This is the heart of the matter, and I agree completely. What I can't >see is how anyone can feel that the main CPU should be wasted in error >logging and retries, bad sector mapping, and handling multiple interrupts. ^^^^^^^^^^^^^^^^^^ Warning - soapbox: Have you ever had an I/O benchmark ruined by a bad sector in the middle of a file? Or, worse, real-life performance on an application? Prefetch is set up right, the disk is tuned, you read in one sector after another, sequentially sucking up the track, and then there's a remapped sector: now you're out of sequence, ouch! You can spend two rotations handling a bad sector remapping if it happens to be in exactly the wrong place... ouch! Track remapping can be even worse: the head is stepping fairly smoothly down the middle of the disk, when wham! it has to go to the end of the disk to find the remapped track - which probably requires a recalibration, and another long seek and recalibration to get back to where you left off. If errors are at all likely to occur on the disk, the filesystem should be able to handle them - not by remapping, but by just stepping around them. -- --- Andy Glew, glew@ichips.intel.com Intel Corp., M/S JF1-19, 5200 NE Elam Young Parkway, Hillsboro, Oregon 97124-6497 This is a private posting; it does not indicate opinions or positions of Intel Corp.