using multiple defbootstr commands

[Adrian]

Hi,

until I rebuild the kernel I was using:
defbootstr nbuf=90000
to change the value of nbuf.

Is there a way to define more than one kernel parameter at the Boot:
prompt?

Cheers,

adrian

[Jean-Pierre Radley]

Adrian propounded (on Wed, Oct 17, 2001 at 09:55:29AM +1000):

|
| until I rebuild the kernel I was using:
| defbootstr nbuf=90000
| to change the value of nbuf.

Why do you need to specify nbuf every time you reboot?

| Is there a way to define more than one kernel parameter at the Boot:
| prompt?

Sure. /etc/default boot probably already defines three or four items.

--
JP

[Adrian]

Hi,

until i found out how long it took to rebuild the kernel i needed to
test the effect of changing various parameters.
of course, now i know that i can rebuild the kernel at will, without
impacting the users too much, i will do it that way.

thanks for the tip about /etc/default

adrian

[Jean-Pierre Radley]

Adrian propounded (on Wed, Oct 17, 2001 at 01:39:44PM +1000):

| Jean-Pierre Radley wrote:
| >
| > Adrian propounded (on Wed, Oct 17, 2001 at 09:55:29AM +1000):
| > |
| > | until I rebuild the kernel I was using:
| > | defbootstr nbuf=90000
| > | to change the value of nbuf.
| >
| > Why do you need to specify nbuf every time you reboot?
| >
| > | Is there a way to define more than one kernel parameter at the Boot:
| > | prompt?
| >
| > Sure. /etc/default boot probably already defines three or four items.
| >

Top-posting reverted. Please don't do it: let answers folloq questions.

| until i found out how long it took to rebuild the kernel i needed to
| test the effect of changing various parameters.
| of course, now i know that i can rebuild the kernel at will, without
| impacting the users too much, i will do it that way.
|
| thanks for the tip about /etc/default

I meant, of course, /etc/default/boot.

You didn't answer my question: why do you think you need to define nbuf?

And why do you think you need a new kernel either?

--
JP

[Adrian]

Jean-Pierre Radley wrote:

>
> | until i found out how long it took to rebuild the kernel i needed to
> | test the effect of changing various parameters.
> | of course, now i know that i can rebuild the kernel at will, without
> | impacting the users too much, i will do it that way.
> |
> | thanks for the tip about /etc/default
>
> I meant, of course, /etc/default/boot.
>
> You didn't answer my question: why do you think you need to define nbuf?
>

we were having performance problems and nbuf had been left at default.
By increasing it to 90000 i found that our performance increased
considerably.
I want to do more than one change, such as CACHEENTS and NHINODE, as
well.

> And why do you think you need a new kernel either?
>

i see, are you saying that if I add the values to /etc/default/boot then
these values will override the values in the kernel.

and if so, do I add the values above AUTOMOUNT=YES?
e.g.
DEFBOOTSTR=hd(40)unix swap=hd(41) dump=hd(41) root=hd(42)
DEFBOOTSTR NBUF=90000
DEFBOOTSTR CACHEENTS=880
DEFBOOTSTR NHINODE=2048
AUTOBOOT=YES

and what about values changed using "idtune"? would i do that here?

thanks for any help,

adrian

[Bela Lubkin]

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=".

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.

>Bela<

[Adrian]

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