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