Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!munnari.OZ.AU!news.mel.connect.com.au!news.mira.net.au!vic.news.telstra.net!act.news.telstra.net!psgrain!usenet.eel.ufl.edu!gatech!news.mathworks.com!fu-berlin.de!irz401!orion.sax.de!uriah.heep!news
From: j@uriah.heep.sax.de (J Wunsch)
Newsgroups: comp.os.linux.networking,comp.unix.bsd.freebsd.misc
Subject: Re: TCP latency
Date: 18 Jul 1996 12:29:26 GMT
Organization: Private BSD site, Dresden
Lines: 65
Message-ID: <4slan6$53o@uriah.heep.sax.de>
References: <4paedl$4bm@engnews2.eng.sun.com>
<31E7BD6F.167EB0E7@dyson.iquest.net> <4s8sau$jsh@fido.asd.sgi.com>
<31E80933.41C67EA6@dyson.iquest.net> <4saf55$dl5@verdi.nethelp.no>
<87k9w6g6u4.fsf@localhost.xs4all.nl> <31E9D0CC.41C67EA6@dyson.iquest.net>
<87ybklz05q.fsf@localhost.xs4all.nl> <31EAD699.41C67EA6@dyson.iquest.net>
<87ohle1v5h.fsf@localhost.xs4all.nl>
Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch)
NNTP-Posting-Host: localhost.heep.sax.de
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Newsreader: knews 0.9.6
X-Phone: +49-351-2012 669
X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E
Xref: euryale.cc.adfa.oz.au comp.os.linux.networking:45691 comp.unix.bsd.freebsd.misc:23928
(Btw., what is the correct Linux group to post this? It certainly
doesn't belong to networking any more, but it's technical, so advocacy
is as wrong.)
Peter Mutsaers <plm@xs4all.nl> wrote:
> I stil think it is a waste of diskspace that this
> isn't true for FreeBSD; there is no need to link these statically
> as long as all shared libraries reside in /lib (on the root filesystem
> too).
You know us as being conservative though. ;-)
Firstly, the shared libs used to be in /usr/lib, as well as the
non-shared libs on BSD. Thus, they are only available with the /usr
filesystem. You are probably right that stuffing them into /lib
wastes somewhat less space in the root file system. (About 2 MB for
me, from a rough estimation.)
Second, the dynamic loader is in /usr/libexec/. ;)
Finally, i think a lot of developers would have mental problems with
making their /bin/sh dependent of yet another binary... i know that
some people run all binaries shared, with the option to fallback to
the fixit floppy, and the backup tape if something broke. Others
(like me) prefer the fallback to single-user, with the option to
eventually bootstrap the system with itself instead of from the backup
tape...
> This is mainly caused by the fact that things like
> reading a tape in Linux (not a raw device) can occupy all of the
> filesystem-buffer/cache, thus swapping out programs (does that really
> happen, or is it my imagination?). FreeBSD keeps the use of buffers
> for filesystem-caching somewhat limited I think, which often is
> reasonable.
On BSD, you should use the raw device anyway. It avoids the overhead
of passing everything through the buffer cache. (The buffered devices
have other artifacts, depending on the system implementation. For
example, i've been working with Data General's DG/UX, where you had to
shutdown the system in order to get the 20 bytes written to the block
device actually back on the floppy. That's quite natural, the only
*guarantee* to get the data out to the medium is the umount syscall,
but how to umount an unmounted disk? ;-)
> Otoh unpacking tar files is much faster on Linux again.
Even with -o async? Remember, BSD (conservatism warning again :)
defaults to synchronous metadata updates. I know that several people
run their development machines async, i do it myself for /tmp and some
scratch file systems, or temporarily switch to async when removing a
large subdir hierarchy. Since you happen to use both systems, it
would be interesting whether it feels the same if you use async on
both systems.
(Please folks, no debate again about the use{ful,less}ness of async
metadata updates.)
--
cheers, J"org
joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)