No vfs nlock_record kernel parameter on Tru64 V4?

[Geert Van Pamel]

I get the following sys_check error for the VFS layer on a Tru64 V4.0f system:

Operational: flckinfo.recmax ( 10000 ) is above 90% of nlock_record ( 10000 )

I try to perform the following kernel tuning:

/sbin/sysconfig -r vfs nlock_record=20000
nlock_record: unknown attribute

This parameter seems only to exist on Tru64 V5?

Questions:

* Why does sys_check on V4 warns me that this (non existing?) process parameter might be too low?
* How would I otherwise increase this parameter on a Tru64 V4 system?

I cannot upgrade to V5 because I run on an AlphaStation 500 ...

[Pieter 't Hart]

following http://h30097.www3.hp.com/docs//base_doc/DOCUMENTATION/V50_HTML/MAN/MAN5/0152____.HTM

it states :
Some attributes in the following list have corresponding parameters in the system configuration file. If so, the corresponding parameter name in the system configuration file is specified in parentheses following the attribute name.

scrolling down to :
* nlock_record
Maximum number of record locks that may be held by a process. This limit prevents lock structures for any one process from consuming too much kernel memory.

=> no name in parentheses !
==> probably not configurable in sysconfigtab.

it's not clear to me yet what command can set this parameter.

[Pieter 't Hart]

try the command "sysconfig -Q vfs nlock_record"
to see if the OS knows the variable at all

output from V5.1b system:
root@eagle # sysconfig -Q vfs nlock_record
vfs:
nlock_record - type=LONG op=CRQ min_val=1000 max_val=100000

[Martin Moore · Accepted solution]

The nlock_record parameter does exist in V4, but it isn't configurable with sysconfig. What you need to do is specify it in the kernel configuration file and rebuild the kernel. Here's how:

HOSTNAME represents the simple hostname in all uppercase characters.

1. Edit kernel configuration file:

# cd /sys/conf
# cp HOSTNAME HOSTNAME.backup
# vi HOSTNAME
...find options section and add this line:

options nlock_record = 20000

...exit vi

2. Rebuild the kernel:

# doconfig -c HOSTNAME

3. Copy the new kernel to root and reboot:

# cp /vmunix /vmunix.backup
# cp /sys/HOSTNAME/vmunix /vmunix
# shutdown -r now

4. If you want to verify that the change worked, do this after rebooting:

# dbx -k /vmunix
...unimportant warning messages appear...
(dbx) pd nlock_record
...should return "20000"
(dbx) quit

Hope this helps,
Martin

[Geert Van Pamel]

I did some more research on internet.

Apparently it is possible to change this parameter interactively, even on Tru64 V4, with the dbx command.

You can use "assign" - the system keeps the value until the next reboot:

dbx -k /vmunix

(dbx) p nlock_record
10000

(dbx) assign nlock_record=20000
20000

(dbx) p nlock_record
20000

(dbx) quit

The "patch" command allows you to change the kernel parameter in the /vmunix file (it will keep its value until the next kernel build).

Make a copy of the current kernel:

cp /vmunix /vmunix-20090224

dbx -k /vmunix

(dbx) patch nlock_record=20000
20000

(dbx) quit

[Martin Moore]

It is true that you can use dbx to patch the kernel. I didn't mention it because I feel this is a dubious practice when there is another mechanism to change the parameter, as there is in this case. Configuring the kernel by patching it can turn into a maintenance issue; suppose that you needed to rebuild the kernel for some reason, sometime in the future after this incident has faded from memory. If you only used dbx, then you'd lose your change when you rebuilt the kernel.

Martin