Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site umcp-cs.UUCP
Path: utzoo!linus!philabs!cmcl2!seismo!umcp-cs!chris
From: chris@umcp-cs.UUCP (Chris Torek)
Newsgroups: net.unix-wizards
Subject: Re: Memory buffers for a Sun disk server?
Message-ID: <5233@umcp-cs.UUCP>
Date: Fri, 26-Apr-85 17:22:24 EDT
Article-I.D.: umcp-cs.5233
Posted: Fri Apr 26 17:22:24 1985
Date-Received: Sun, 28-Apr-85 05:09:48 EDT
References: <339@linus.UUCP>
Distribution: net
Organization: U of Maryland, Computer Science Dept., College Park, MD
Lines: 30
Keywords: Sun, disk server

Well, it doesn't quite work that way.  "bufpages" is the amount of
memory allocated for buffer space; this is distinct from the number of
buffers ("nbuf") since in 4.2, a buffer is only as big as the disk
block it is supposed to hold.  Pages are moved from one buffer to
another (by zapping pte's) as necessary.  If you have file systems that
are blocked 4k/512, bufpages is generally twice as big as it ought to
be, since the code that allocates nbuf based on bufpages assumes that
buffers average MAXBSIZE bytes.  (This is all ignoring the swap I/O
buffer header stuff, but the swap buffer headers are really just
headers; they point into space that becomes owned by the pagedaemon
during pageouts.)

Anyway, you can increase the number of local buffers by filling in
a value in "nbuf" in /vmunix (it's in initialized data space) and
rebooting.  Turning on "syncprt" (if Sun left it in) will also make
the console show how much buffer memory is in use and how much is
free, which can help you decide what nbuf ought to be set to.

As far as the network disk code goes:  well, increasing nbuf won't make
that much difference, probably, since ndstart() is only willing to
queue up 4 transfers to the server before it waits for one of them to
finish:

	while ((bp = dp->b_actf) != NULL && nd_nsenttoserv < 4) {

and so forth.  But it will help keep useful information cached.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251)
UUCP:	{seismo,allegra,brl-bmd}!umcp-cs!chris
CSNet:	chris@umcp-cs		ARPA:	chris@maryland