Date: Thu, 18 Feb 1999 11:14:56 -0500 From: Robert Sexton <robert@kudra.com> To: freebsd@digistar.com Cc: freebsd-hackers@freebsd.org Subject: Re: data buffers, disk i/o jsb Message-ID: <19990218111456.A2658@kudra.com> In-Reply-To: <Pine.LNX.4.10.9902180827500.1566-100000@digistar.digistar.com>; from freebsd@digistar.com on Thu, Feb 18, 1999 at 08:51:53AM -0600 References: <Pine.LNX.4.10.9902180827500.1566-100000@digistar.digistar.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Feb 18, 1999 at 08:51:53AM -0600, freebsd@digistar.com wrote:
>
> hi,
>
> Is there a compile-time option that I can compile into the kernel to
> improve disk caching/buffering?
FreeBSD self tunes. Because of the Unified VM/Buffer Cache, resource
allocation can change on the fly. Generally, it can tune itself
better than you can.
I'd have to defer to more experienced folks for a detailed explanation.
> My concern/question is I have recently put together a 2.2.8 test server
> and noticed that disk access is not up to expectations and I am looking
> for a way to remedy it.
I guess I'd have to ask what your expectations and needs are.
You also haven't provided any details on your hardware. This is quite
relevant to your question.
> For example, when doing a du or a find across a single slice, the disk is
> physically accessed every time I du or find. I had expected the first
> find or du access to read and buffer the first pass, and the second find
> or du to read from the disk cache or buffer. It seems like there's a lot
> of wasted disk i/o when it could be avoided by reading from the disk
> cache.
This depends on the nature of the filesystem, and whats in it. In the
case of /usr/ports, the tree is so mind bogglingly huge that it blows
out most of the relevant caches.
> Also, if I boot from the boot floppy for installtion and install the ports
> collection, the install moves at a much faster pace, like 15K/s. If I
> install the ports collection after the install is completed (booting from
> the hard disk) the install takes FOREVER, like 2K/s and there is a HUGE
> amount of disk access.
This really can't be helped. The ports filesystem on one of my
production machines contains almost 30k inodes.
Building it is a nightmare. I'm told it'll build quite quickly on an
asyncronous filesystem. (See Below)
> Is there a compile-time option that I can compile into the kernel to
> improve disk caching/buffering?
None that I'm aware of. However, there are a number of other, better options.
a. Mount filesystems with the noatime flag.
This elimates a lot of inode updates when walking a large tree.
b. Mount filesystems async. This provides terrific performance
on large trees like ports, but is the digital equivalent of
no seatbelts in a convertable.
c. Switch to 3.0 and uses soft updates. This gives you most of the
performance of async, but with a high degree of safety.
--
Robert Sexton - robert@kudra.com, Cincinnati OH, USA
As a software development model, Anarchy does not scale well. -Dave Welch
Read the Newton FAQ! <http://www.kudra.com/newton/newton-faq>;
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990218111456.A2658>