Xref: utzoo comp.protocols.nfs:1896 comp.arch:21293 Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!fuug!demos!avg From: avg@hq.demos.su (Vadim Antonov) Newsgroups: comp.protocols.nfs,comp.arch Subject: Re: disk queues of length zero..... Message-ID: <1991Mar7.115154.4820@hq.demos.su> Date: 7 Mar 91 11:51:54 GMT References: <28975@cs.yale.edu> <1991Mar5.223443.21187@ns.uoregon.edu> <1991Mar6.003008.9131@bellcore.bellcore.com> Organization: DEMOS, Moscow, USSR Lines: 23 In <1991Mar6.003008.9131@bellcore.bellcore.com> mo@messy.bellcore.com (Michael O'Dell) writes: > Assume you memory map and create large file on a machine with lots > of free memory. Say you write 50 megabytes. You now close > the file and hence ask for it to really go to disk. > WHAM! 50 megabytes goes on the disk queue. Yes this does happen, > and boy, is the poor dweeb at some other terminal who just > typed "ls" on the same filesystem really screwed. I'm worrying why Unix does lack any mechanisms of disk idle time utilization? I think it's the solution of the problem - low-priority lazy updating of modifyed disk blocks. No need to sync. No such "surprizes" as described before. No need to write down from a cache buffer when you urgently need a free one. Of course, there is no such thing as a free lunch and this method has some drawbacks: Most disk controllers cannot interrupt a seek operation and it leads to extra latency for normal priority i/o. Extra interrupts. Unix already is well-known as a disk killer :-) due to rather intensive random-pattern seeks and the proposed enchancement will make the behaviour even worse (btw, I think it's a hardware designer's headache :-). After all the improvement is not so complex and I think it worth to try. Vadim Antonov DEMOS, Moscow, USSR