Return to BSD News archive
Xref: sserve comp.os.386bsd.questions:12455 comp.os.386bsd.misc:3260 Newsgroups: comp.os.386bsd.questions,comp.os.386bsd.misc Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!bunyip.cc.uq.oz.au!munnari.oz.au!constellation!news.uoknor.edu!ns1.nodak.edu!netnews.nwnet.net!pnl-oracle!osi-east2.es.net!lll-winken.llnl.gov!sol.ctr.columbia.edu!howland.reston.ans.net!math.ohio-state.edu!jussieu.fr!univ-lyon1.fr!swidir.switch.ch!newsfeed.ACO.net!Austria.EU.net!EU.net!uunet!brunix!mhw From: mhw@cs.brown.edu (Mark Weaver) Subject: Re: Whats wrong with Linux networking ??? Message-ID: <1994Aug15.175932.10899@cs.brown.edu> Sender: news@cs.brown.edu Organization: Brown University Department of Computer Science References: <RSANDERS.94Aug9003813@hrothgar.mindspring.com> <32ll52$n7d@quagga.ru.ac.za> <1994Aug15.034939.20997@cs.brown.edu> <michaelv.776931077@ponderous.cc.iastate.edu> Date: Mon, 15 Aug 1994 17:59:32 GMT Lines: 34 In article <michaelv.776931077@ponderous.cc.iastate.edu>, Michael L. VanLoon <michaelv@iastate.edu> wrote: >In <1994Aug15.034939.20997@cs.brown.edu> mhw@cs.brown.edu (Mark Weaver) writes: > >>Typically running X, compiling, and perhaps dragging around xterms >>or reading manual pages at the same time. To be honest, I'm not >>exactly sure that it's thrashing, but I get one hell of a lot of >>disk activity. I always get significant disk activity from compiling, >>even though my /tmp is a ramdisk. > >>On Linux, while doing the same thing, there is hardly any disk >>activity at all. I always think something's wrong when compiling >>under Linux because I don't hear the characteristic disk chattering >>that I associate with compiling. > >Actually, what you're experiencing might not be VM swapage at all, but >rather synchronous writes to disk. From what I understand, from other >posts on this subject, Linux delays writing everything to disk until >buffers get flushed. Whereas *BSD always writes superblock/inode/ >whatever data immediately to disk, and only delays writing actual data >blocks until buffers flush. This causes *BSD to be a little slower in >asynchronous disk benchmarks and such, but causes it to trash the >drive much less severely if your machine were to crash, say, in the >middle of a large compile. I'm aware of the synchronous writes issue, but again, my /tmp is a ramdisk, and gcc is using /tmp for it's temporary files (I checked), and it should only be writing one file per source file, so I shouldn't be getting NEARLY that much disk chattering. Mark -------------------------------------------------------------------- Email: Mark_Weaver@brown.edu | Brown University PGP Key: finger mhw@cs.brown.edu | Dept of Computer Science