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