mo@messy.bellcore.com (Michael O'Dell) (03/06/91)
I know *I* have seen servers with much longer disk queues. For example - 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. There are many more anomolies out there when the machine and the memory get sufficiently fast and large.... -Mike
rsc@merit.edu (Richard Conto) (03/07/91)
In article <1991Mar6.003008.9131@bellcore.bellcore.com> mo@bellcore.com (Michael O'Dell) writes: > 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. So, when doing memory mapped files like this, why not tell the server to set aside (preallocate) the disk space as the file is filling up on the client? That does mean more overhead, but it does make it more certain that the server won't reject the file when it is placed on the server. Sounds like a poor implementation to me (or a bad design). The concept should work, even in extreme cases like the above. --- Richard ( rsc@merit.edu, Richard_Conto@um.cc.umich.edu )
avg@hq.demos.su (Vadim Antonov) (03/07/91)
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
lm@slovax.Eng.Sun.COM (Larry McVoy) (03/08/91)
In article <1991Mar7.115154.4820@hq.demos.su>, avg@hq.demos.su (Vadim Antonov) writes: |> 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. System 5 r 4 has this. We call it the incer-syncer (incremental sync). -- --- Larry McVoy, Sun Microsystems (415) 336-7627 ...!sun!lm or lm@sun.com