Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ukma!gatech!udel!mmdf
From: HELMER%SDNET.BITNET@vm1.nodak.edu (Guy Helmer)
Newsgroups: comp.os.minix
Subject: Re: Disk performance under Minix
Message-ID: <21837@louie.udel.EDU>
Date: 16 Aug 89 16:40:17 GMT
Sender: mmdf@udel.EDU
Lines: 31

In a recent article, evans@ditsyda.oz (Bruce Evans) writes:
>In article <21693@louie.udel.EDU> HELMER%SDNET.BITNET@vm1.nodak.edu (Guy
>Helmer)
> writes:
>>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
>
>One of the ingredients in my speedups was to remove this. (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.
>Extending files is another bad case for the high-integrity method. It
>doubles the i/o, and extra seeks may cost much more.

I hestitated to suggest this speedup since I believe it diverges
from the AT&T un*x design, according to Bach in _The Design of the Un*x
Operating System_ chapter 4 - algorithm iput (page 66)|.  I do believe
the speed increase in write operations justifies the change, though.

>I also changed the cache flushing method so all dirty blocks on a device
>are flushed whenever one needs to be flushed. This helps keep the integrity.
>It may actually be safer - less wear.
>--
>Bruce Evans		evans@ditsyda.oz.au

Thanks for the info.

-- Guy Helmer
   BITNET: HELMER@SDNET