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