News Group Posts

DEFBOOTSR nbuf

From: Adrian <adrian@adrianworld.com>
Subject: Re: using multiple defbootstr commands- thanks
References: <3BCCC8F1.35E58918@adrianworld.com>
<20011016203155.D27256@jpradley.jpr.com>
<3BCCFD80.F107A309@adrianworld.com>
<20011016235713.I27256@jpradley.jpr.com>
<3BCD0C1B.E962FF59@adrianworld.com>
<20011020121807.W5148@mammoth.ca.sco.com> 
Date: Tue, 23 Oct 2001 13:49:46 +1000


Bela Lubkin wrote:
> 
> Adrian>>> until i found out how long it took to rebuild the kernel i needed to
> Adrian>>> test the effect of changing various parameters.
> Adrian>>> of course, now i know that i can rebuild the kernel at will, without
> Adrian>>> impacting the users too much, i will do it that way.
> Adrian>>>
> Adrian>>> thanks for the tip about /etc/default
> 
> JPR>> I meant, of course, /etc/default/boot.
> JPR>>
> JPR>> You didn't answer my question: why do you think you need to define nbuf?
> 
> Adrian> we were having performance problems and nbuf had been left at default.
> Adrian> By increasing it to 90000 i found that our performance increased
> Adrian> considerably.
> Adrian> I want to do more than one change, such as CACHEENTS and NHINODE, as
> Adrian> well.
> 
> JPR>> And why do you think you need a new kernel either?
> 
> Adrian> i see, are you saying that if I add the values to /etc/default/boot then
> Adrian> these values will override the values in the kernel.
> 
> I'd like to correct several misconceptions in this discussion.
> 
> "DEFBOOTSTR" is not a command at all.  It is a bootstring macro defined
> in /etc/default/boot.  /etc/default/boot is read by the boot program
> (/stand/boot, boot(HW)).  It looks for a number of predefined parameters
> such as AUTOBOOT.  Any "name=value" in /etc/default/boot which isn't one
> of those predefined parameters is understood as a boot macro.  If you
> put "foo=bar" in /etc/default/boot, then you can type "foo" at the boot
> prompt and you'll get a message about how "bar" wasn't found.
> 
> DEFBOOTSTR is one of those macros.  It's special in that, if you hit
> return at the boot prompt, or allow it to time out and autoboot, boot
> acts as if you had entered "defbootstr".
> 
> Whenever you enter "defbootstr something else", you are simply invoking
> the default bootstring macro with some extra parameters added at the
> end.
> 
> The general form of a /stand/boot command line is: the first word is the
> name of a standalone program to run (usually the name of a Unix kernel);
> all other words are parameters to be passed to that program.
> 
> The parameter that you were using was "nbuf=#".  This works, but should
> not be mistaken as a general rule about kernel parameters.  The kernel
> does not generally accept tunable parameter values on its command line.
> It accepts "nbuf=#" only because someone decided that that specific
> parameter would be useful to override at boot time.  So the kernel
> specifically checks for "nbuf=#".
> 
> Adrian> and if so, do I add the values above AUTOMOUNT=YES?
> Adrian> e.g.
> Adrian> DEFBOOTSTR=hd(40)unix swap=hd(41) dump=hd(41) root=hd(42)
> Adrian> DEFBOOTSTR NBUF=90000
> Adrian> DEFBOOTSTR CACHEENTS=880
> Adrian> DEFBOOTSTR NHINODE=2048
> 
> This would not work because the syntax is wrong.  In the first line,
> you're defining DEFBOOTSTR.  The next three lines are just syntax
> errors.  _IF_ the kernel accepted "cacheents=" and "nhinode=" on its
> command line, you could have written:
> 
>   DEFBOOTSTR=hd(40)unix swap=hd(41) dump=hd(41) root=hd(42) NBUF=90000 CACHEENTS=880 NHINODE=2048
> 
> But this would just get you error messages from the kernel, since it
> doesn't recognize "cacheents=" or "nhinode=".
> 

i imagine this would have been bad news at boot time...



> Adrian> and what about values changed using "idtune"? would i do that here?
> 
> idtune (or configure(ADM)) is the right way to change kernel parameters.
> The kernel command-line recognition of "nbuf=" was really only added for
> the benefit of installation.  It's slightly useful to users in that it
> allows twiddling that one parameter without the relink step, but
> relinking isn't very painful on current hardware; rebooting is much
> slower, and "nbuf=" doesn't get you out of rebooting, so there's really
> very little benefit.
> 

ok,  rebuilding the kernel is the way to go.  


thank you for these very useful bits of info.

adrian
 

Comments?

Jump to Comments

Many of the products and books I review are things I purchased for my own use. Some were given to me specifically for the purpose of reviewing them. I resell or can earn commissions from the sale of some of these items. Links within these pages may be affiliate links that pay me for referring you to them. That's mostly insignificant amounts of money; whenever it is not I have made my relationship plain. I also may own stock in companies mentioned here. If you have any question, please do feel free to contact me.

Specific links that take you to pages that allow you to purchase the item I reviewed are very likely to pay me a commission. Many of the books I review were given to me by the publishers specifically for the purpose of writing a review. These gifts and referral fees do not affect my opinions; I often give bad reviews anyway.

We use Google third-party advertising companies to serve ads when you visit our website. These companies may use information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide advertisements about goods and services of interest to you. If you would like more information about this practice and to know your choices about not having this information used by these companies, click here.