NetNews Usenet Archive 1992 #20/NN_1992_20.iso/spool/comp/unix/ultrix/6893

Text File | 1992-09-14 | 2.9 KB | 72 lines

Newsgroups: comp.unix.ultrix
Path: sparky!uunet!decwrl!pa.dec.com!nntpd2.cxo.dec.com!nabeth!alan
From: [e-mail] (Alan Rollow - Alan's Home for Wayward Tumbleweeds.)
Subject: Re: kernel configuration recommendations?
Message-ID: <[e-mail]>
Lines: 59
Sender: alan@nabeth (Alan Rollow - Alan's Home for Wayward Tumbleweeds.)
Reply-To: [e-mail] (Alan Rollow - Alan's Home for Wayward Tumbleweeds.)
Organization: Digital Equipment Corporation
References: <[e-mail]> <[e-mail]>
Date: Mon, 14 Sep 1992 20:30:22 GMT


In article <[e-mail]>, [e-mail] (Eiji Hirai) writes:
>
>[e-mail] writes:
>> if there's any general advice to be had i'd appreciate it a lot.
>
>I've heard some folks say that enabling cache_bufcache in
>/usr/sys/conf/mips/param.c is an easy win:
>
>> int     cache_bufcache = 1;
>
>I've had this kernel running on our DEC 5000/200, Ultrix 4.2a systems for a
>month now.  However, don't blame me if this crashes your system. :-)
>

Setting cache_bufcache is recommended (supported) in V4.3.  It works
nicely with the I/O enhancer support.  I have also used it on V4.2
without much trouble.

On the subject; you can change the behaviour of writting from the
buffer cache using delay_wbuffers.  You may not want to though, it
will depend on the application and the result that you are trying
to achieve.

There are three choices for file system writes.

1.  Synchronous.  There are a number of ways to do this.  See the
    manual pages for fsync(2), fcntl(2), mount(8).

2.  Non-delayed writes.  This is the default.  When a high level file
    system transfer ends on a block boundry the block will be written
    one of two ways.  The non-delayed way starts the write and continues
    on.  A read of the buffer will block until the write is done.

3.  Delayed writes.  The other case of #2.  The buffer is just marked
    as being done, eligible for delayed write and released.  It will
    be written during a sync(2) or fsync(2), or when a buffer is needed
    and it has to be flushed before use by someone else.

    Doing writes this way it is possible to write a large file, just
    smaller than the buffer cache, that causes very little I/O until
    you flush the cache somehow.  This sort of behaviour might be
    useful for temporary files that don't really need to be saved
    through system crashes.  It's possible the lifetime of the time
    is short enough the data will never be written to disk.

    However if you do intended to really save the data, you're going
    to have to pay for the write eventually.  Delayed writes are much
    safer.

    I believe the documentation on the I/O enhancer recommends that
    you DO NOT set delay_wbuffers.

>--
>Eiji Hirai <[e-mail]>
>
--
Alan Rollow                [e-mail]