Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!cs.utexas.edu!uunet!murtoa.cs.mu.oz.au!munnari.oz.au!otc!metro!extro!natmlab!ditsyda!evans
From: evans@ditsyda.oz (Bruce Evans)
Newsgroups: comp.os.minix
Subject: Re: Disk performance under Minix
Message-ID: <2131@ditsyda.oz>
Date: 15 Aug 89 18:49:02 GMT
References: <21693@louie.udel.EDU>
Reply-To: evans@ditsyda.mq.oz (Bruce Evans)
Organization: CSIRO DIT Sydney, Australia
Lines: 18

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 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