Return to BSD News archive
Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!simtel!lll-winken.llnl.gov!hookup!solaris.cc.vt.edu!news.mathworks.com!gatech!howland.reston.ans.net!nntp.crl.com!decwrl!svc.portal.com!news1.best.com!blob.best.net!not-for-mail
From: dillon@best.com (Matt Dillon)
Newsgroups: comp.unix.bsd.freebsd.misc
Subject: Re: FreebBSD 2.0.5-R crashes every 2 DAYS!!
Date: 26 Jul 1995 13:13:09 -0700
Organization: Best Internet Communications, Inc. (info@best.com)
Lines: 94
Distribution: world
Message-ID: <3v67kl$inn@blob.best.net>
References: <3urlmb$7co@ucsbuxb.ucsb.edu> <3us8mc$17j@agate.berkeley.edu> <3uu8ao$4ts@blob.best.net> <3v30fc$ep4@dingo.cc.uq.oz.au>
NNTP-Posting-Host: blob.best.net
:In article <3v30fc$ep4@dingo.cc.uq.oz.au>,
:Robert Brockway <ec531667@student.uq.edu.au> wrote:
:>Followups have been set tp comp.os.linux.advocacy
:>
:>...
:>on linux kernels is useful, making it trivial to know whether a kernel
:>is stable or development at a glance.
:>
:>: think Linux is an excellent choice for a home machine. Taking
:>: performance into account makes the situation even less tenable. While
:>: I admire all the work that has gone into Linux, it is simply too
:>: inefficient for a production system: Disk I/O and network performance
:>: is abysmal and I could never load it down as heavily as I load down
:>: our FreeBSD machines. But, again, for a home system, Linux is fine.
:>
:>It is interresting that you should say these things as they are in
:>direct opposition to what i know to be true. Due to the e2fs which
:>is an asynchronous fs, linux achieves better disk i/o over most disk
:>functions than FreeBSD (or NetBSD, or WinNT). As for network performance
:>i can't really say, but i believe (with the exception of nfs) that Linux
:>is on a par with FreeBSD. As for loading, tests carried out by a company
:>evaluating various PC-Unices in the US found that Linux operated the most
:>efficiently under loads up to 25. Since no one in there right mind would
:>run a machine with a system load of 25 (have you ever seen a load
:>of 10? :-) this makes Linux the most efficient under heavy load for all
:>usable system loads.
Well, I think you really need to install up a FreeBSD 2.0.x release
on a machine and get up to speed a bit on the differences. I have
the two side by side and there is really no comparison when it
comes to I/O throughput. Linux compares well against 4.3 based
BSD's, but not so well against 4.4 based BSD's.
I see people using the fact that the ext2fs does not commit its inodes
synchronously as an excuse to advocate, wrongly, that extfs beats
the pants off of ffs/ufs. In fact, the exact opposite is true for
everything *except* possibly an rm -rf or the creation of lots of
really tiny files at once.
What most people do not seem to realize is that a one or two line
change in the FreeBSD kernel will turn those synchronous commits into
asynchronous and make the filesystem blow past ext2fs like the breeze
for rm -rf / file creates.
I don't know anyone who does it though... most people like the
extra little robustness in ufs/ffs and don't mind the performance
loss, especially considering the relatively few conditions where
that type of performance might be required.
(Side note: Ext2FS seems just as recoverable as UFS.. the asynchronous
nature of the inode commit under Ext2FS has not in my experience
caused greater file loss / corruption when a panic or power loss
occurs then UFS).
The main I/O throughput problem under linux seems to be due to
inefficiencies in the block I/O and caching design.
--
The networking inefficiencies under Linux are well known. It
is mainly a design problem, with NFS needing the most help. The
route tables need some help too... FreeBSD has a wonderful route
table / route cache design which goes a long way to speeding up
the stacks.
:>My intention is not to start a flame war, or OS bashing war, as we have
:>too many of those already, but i have followed up to comp.os.linux.advocacy
:>to keep flames/OS bashing out of misc groups.
:>
:>And now for something completely different:
:>I take it that the Matt Dillon i am following up to is not the same
:>Matthew Dillon of 'Dillon's cron' ? The email addresses are different,
:>but these things change. If crond is your program, i would like to
:>congratulate you on a fine piece of work.
:> -Robert
:>
:>--Robert Brockway, email: ec531667@student.uq.edu.au
:> WWW: http://student.uq.edu.au/~ec531667
:> snail mail: never mind.
:>I'll try anything once, and if i like it, i'll take it up as a hobby!
I am that Matt dillon. Through the years I've gone through a huge
number of domain name changes... most of them still out to route to
me.
Thanks for the complement! I wrote it out of frustration for the
Vixie crond that, under linux, was causing a lot of people including
me no end of grief. To be fair, it wasn't really Paul's fault... a
whole lot of people had hacked the cron source for linux and introduced
some pretty nasty bugs in the process. Still, I was so unhappy with
the basic design that I just up and wrote a new cron from scratch.
-Matt