Return to BSD News archive
Xref: sserve comp.os.386bsd.misc:1256 comp.os.linux:56374 Path: sserve!newshost.anu.edu.au!munnari.oz.au!constellation!osuunx.ucc.okstate.edu!moe.ksu.ksu.edu!hobbes.physics.uiowa.edu!math.ohio-state.edu!howland.reston.ans.net!spool.mu.edu!bloom-beacon.mit.edu!news.kei.com!news.byu.edu!cwis.isu.edu!u.cc.utah.edu!cs.weber.edu!terry From: terry@cs.weber.edu (A Wizard of Earth C) Newsgroups: comp.os.386bsd.misc,comp.os.linux Subject: Re: FYI.. benchmarks on linux and 386bsd Date: 16 Oct 1993 06:39:54 GMT Organization: Weber State University, Ogden, UT Lines: 33 Message-ID: <29o4vq$rfg@u.cc.utah.edu> References: <2CB12A8D.17397@news.service.uci.edu> <MYCROFT.93Oct6054959@duality.gnu.ai.mit.edu> <29klpf$8ae@kralizec.zeta.org.au> NNTP-Posting-Host: cs.weber.edu In article <29klpf$8ae@kralizec.zeta.org.au> bde@kralizec.zeta.org.au (Bruce Evans) writes: >In <MYCROFT.93Oct6054959@duality.gnu.ai.mit.edu> mycroft@duality.gnu.ai.mit.edu (Charles Hannum) writes: > >>1) When diddling lots of small files or other operations on file >>system metastructure, one must consider that Linux uses write-behind >>for this and therefore risks serious file system corruption should the >>machine crash. (Back when Linux crashed a couple of times per day for >>me, I had no end of file system corruption which caused me to have to >>reinstall. I assume it does not crash that often now, but this is >>still a serious bug.) This also makes Linux's file systems faster. > >A measly 10 to 20 times faster. This is one thing makes Linux "feel" >much faster (up to 10 to 20 times :-) than 386BSD. The same speed enhancements can be had by throwing out POSIX modification time update compliance for inodes and/or performing elevator seeking on writes for seek and flush updates. There are also a number of magic things that should be obvious in terms of establishing per process disk buffer "working set quotas". A second set of "magic" can be had by using mmap()'ed stdio libs IFF there is a unified VM and buffer cache so the only thing that happens on a read/write is a ptdi swap (ie: the copyin/copyout is avoided). Write behind isn't that big a thing for anything other than sustained sequential I/O. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.