Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.carno.net.au!harbinger.cc.monash.edu.au!not-for-mail
From: mmcg@heraclitus.cs.monash.edu.au (Mike McGaughey)
Newsgroups: comp.unix.bsd.freebsd.misc
Subject: Re: Hard disk transfer speeds really slow.
Date: 22 Apr 1997 13:02:32 GMT
Organization: Monash University
Lines: 54
Message-ID: <5jict8$g1a$1@harbinger.cc.monash.edu.au>
References: <335D9D70.D63@socs.uts.edu.au>
NNTP-Posting-Host: heraclitus.cs.monash.edu.au
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Newsreader: knews 0.9.7
Xref: euryale.cc.adfa.oz.au comp.unix.bsd.freebsd.misc:39521
Last Wed, Martin Gisch <mgisch@socs.uts.edu.au> wrote:
> During installation I get HD transfer speeds of about 150K/sec! Is that
> normal? It took about 15 mins to extract the ports collection, and thats
> only a 3MB tar file.
Oh, the ports collection is something of a special case - about
10000 small files. Since file writes are synchronous (there's no
`write-cache' enabled by default), extracting this tar file to disk
takes an enormous amount of time, because of disk seeks, etc, caused
by updating directory entries between each file write (it's still
a lot faster than dos - try it :).
On the other hand, I just extracted ports-2.2 to a mfs partition in
under a minute (on a P90, with considerable swapping) - so this is
how fast it might go if you mounted your file system asynchronous.
NB: Asynch mounts are really very slick for tasks involving the
creation of large numbers of small files. However, these tasks
don't occur very often, and the danger with asynch is that you'll
completely screw your file system if you knock your reset button
(with normal mounts, fsck will usually do a good job of recovery).
I used to use asynch all the time - and now that I've switched back (out
of caution), I only occasionally notice the difference. In fact, this
is the main reason why I use mfs - to handle things like the ports collection.
> Is there some sort of disk caching available for FreeBSD?
It's built in, and it works well (both read-caching and write-behind
are available; read-caching is always enabled, and write-behind is
asynch mode). `man mount' for how to turn on asynch mode.
It's also possible to implement a `reasonably safe' (i.e. `recoverable
in the case of a crash') asynch file system by scheduling data
writes before inode writes, and inode writes before directory
updates (and probably a bunch of other ordering constraints which
depend on which file system you're using) - this way, in the case
of a crash, the lost writes show up as missing blocks when you
fsck, but your directory structure isn't also hosed. You can easily
tune such a system (e.g. by specifying how many seconds of data
writes you're prepared to lose in the case of a crash, so that
update scheduling for the higher levels of the file system can be
changed from anywhere between fully synchronous to fully asynchronous).
But this is probably something for the future.
Cheers,
Mike.
--
Mike McGaughey AARNET: mmcg@cs.monash.edu.au
"Thousands at his bidding speed,
And post o'er land and ocean without rest" - Milton.