Path: utzoo!utgpu!watmath!iuvax!rutgers!gatech!udel!mmdf
From: HELMER%SDNET.BITNET@vm1.nodak.edu (Guy Helmer)
Newsgroups: comp.os.minix
Subject: Re: Disk performance under Minix
Message-ID: <21693@louie.udel.EDU>
Date: 14 Aug 89 21:34:47 GMT
Lines: 42

In a recent article, nfs@notecnirp.princeton.edu (Norbert Schlenker)
writes:
>In article <21290@louie.udel.EDU> HELMER%SDNET.BITNET@vm1.nodak.edu (Guy
>Helmer)
> writes:
>>Bruce Evans' work on improving floppy disk performance got my curiosity
>>up, so I did a little unscientific test of i/o to my hard disk under
>>Minix and PC-DOS.  I wrote a little program that wrote 256 1024-byte
>>blocks to a file using fopen/fwrite.  Under PC-DOS, this program
>>took 5 seconds to write the file.  Under Minix, this program took
>>18 seconds to run.  This is on a 20Mhz 80386 machine with standard
>>AT-style controller and a 40Mb ST-251 disk with 1:2 interleave.
>> ... machine description deleted ...|
>>
>>-- Guy
>>   BITNET: HELMER@SDNET
>
>This seemed a bit curious to me, so I tried it on my system too
>(16MHz 80386 with a Conner drive and RLL controller that appears to
>cache tracks).  A DOS program finishes in about 6 seconds; a Minix
>program takes 20 seconds (elapsed) / 5.8 (user) / 0.6 (system).
> ... mention of improved stdio code, etc. ...|
>
>Norbert

I have been discussing this with Bruce Evans.  It appears that
the small buffer cache will cause Minix hard disk i/o to slow to a crawl.
From just observing the behavior of the program I described above, it
seems that after the buffer cache gets full the disk begins seeking
intensely, as though it is going back to the superblock / inode table /
free block table between every few physical writes.

From The Book, lines 8161-8167 (documentation for put_block() in fs/cache.c)
say that "Blocks whose loss can hurt the integrity of the file system (e.g.
inode blocks) are written to the disk immediately if they are dirty."  Hmmm...
A file's inode would get modified quite often during the kind of i/o
that we are doing here, and put_block() might be called on the cached inode
block every time another block was allocated for a file.  I'll do a little
research and see if I'm on the right track.

-- Guy Helmer
   BITNET: HELMER@SDNET