Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cwjcc!gatech!udel!mmdf From: HELMER%SDNET.BITNET@vm1.nodak.edu (Guy Helmer) Newsgroups: comp.os.minix Subject: Re: Disk performance under Minix Message-ID: <21978@louie.udel.EDU> Date: 18 Aug 89 15:02:26 GMT Sender: mmdf@udel.EDU Lines: 54 >In article <18613@princeton.Princeton.EDU> nfs@notecnirp.UUCP (Norbert > Schlenker) writes: >>In article <21290@louie.udel.EDU> HELMER%SDNET.BITNET@vm1.nodak.edu (Guy > Helmer) writes: >>> ... ancient remarks deleted ...| > . . . . >>The copy through the buffer >>cache struck me as another possible culprit > >Considering that DOS uses a write-through cache -- i.e. writes are NEVER >delayed -- I don't see how MINIX's delayed-write cache could possibly >contribute to a slowdown in output. All other things being equal, doesn't >a delayed-write cache guarantee higher throughput? The delayed-write cache normally results in higher output rates, but when it is combined with standard Minix's attempts at maintaining file system reliability (by writing Very Important Blocks to disk immediately after modification), things get very slow. >In article <2131@ditsyda.oz> evans@ditsyda.oz (Bruce Evans) writes: >>(Remove the >>WRITE_IMMED's from all but the super block and map blocks in fs/buf.h.) >>It had an immediate huge effect on the time for "rm *" in a bug directory. > . . . . >>I also changed the cache flushing method so all dirty blocks on a device >>are flushed whenever one needs to be flushed. > >Bruce, do you have actual timings to show how much performance is increased? >Does it approach DOS' performance? I removed the WRITE_IMMED's from buf.h and then re-tried my tests. For the 256 1k block fopen/fwrite test, timings improved from ~18sec real time (so awful that I didn't even bother to get an accurate average) to a mean of 9.60sec (mean of 5 tries) real time on my 20Mhz 80386 machine with a 28ms hard disk. Here's the complete info: fwrite write Test Real User Sys Real User Sys 1 9.0 5.3 0.5 5.0 0.0 0.4 2 10.0 5.4 0.4 5.0 0.0 0.5 3 10.0 5.2 0.4 5.0 0.0 0.3 4 10.0 5.4 0.4 5.0 0.0 0.5 5 9.0 5.3 0.4 5.0 0.0 0.4 Note that with this mildly modified FS, Minix is very close to being as fast as good old DOS. Like any other O/S, a little testing would reveal areas of the FS code where more performance could be gained. >Greg Hinton >INET: hinton@netcom.uucp >UUCP: ...!uunet!apple!netcom!hinton -- Guy Helmer BITNET: HELMER@SDNET