fs_meta_max

[Anar Veliyev]

Hi.

We got two servers "ia64 hp server rx7640" and "ia64 hp server rx3600" with "HP-UX B.11.31" on (recently installed).
dmesg has the following warning message:
"Jan 3 11:40:04 vmunix: Warning: The validity of the tunable values could not be completely verified, because the value of the tunable 'fs_meta_max' will not be known until the system is booted. The tunable values will be verified during boot. Please check the console messages during boot to see if there are any tunable value errors."

Values for this parameter as follows:
in rx3600: `kctune fs_meta_max`
Tunable Value Expression Changes
fs_meta_max 978583552 Default Auto

in rx7640: `kctune fs_meta_max`
Tunable Value Expression Changes
fs_meta_max 1466593280 Default Auto

`man fs_meta_max` shows "no manual entry for...".
Searching the web for fs_meta_max too returns no results.
- Does anybody know what does this parameter stands for?
- Have anybody came across the similar "... validity of the tunable values ..." messages in syslog.log and `dmesg`?

Any clue greatly appreciated.

Thanks in advance.
Best Regards.

[James R. Ferguson]

Hi:

> Does anybody know what does this parameter stands for?

I sorry, can't find any information on this either. I might guess that this is a ceiling for the number of inodes in a filesystem which heretofore have been "unlimited" in VxFS filesystems with 'largefiles' enabled.

> Have anybody came across the similar "... validity of the tunable values ..." messages in syslog.log and `dmesg`?

The manpages for 'kctune' say _not-to-worry_:

/* begin_quote */

kctune always checks the validity of tunable values before applying them to the running system. When tunable value changes are held for next boot, or made to a saved configuration, some of the validity checks are not performed until the changed configuration is booted. If any tunable values are found to be invalid, messages will be printed to the system console during the boot process, and the default values for any affected tunables will be used instead.

/* endof_quote */

Regards!

...JRF...

[Anar Veliyev]

Thanks James for time and info.

I did some `strings /var/adm/kc.cache | grep fs_meta` and came across the following lines in:
filecache_min
Minimum guaranteed physical memory used for caching file I/O data
filecache_max
Maximum amount of physical memory to be used for caching file I/O data
fs_meta_min
Minimum guaranteed kernel memory used for metadata in the file cache
fs_meta_max
Maximum kernel memory used for metadata in the file cache

Last 2-3 days we're trying to obtain optimal values for filecache_*, and I suspect the fs_meta_* ones are linked somehow behind the scenes to filecache_* ones. But of course one needs a proof for that "link".

And `vxfstune /mount_point` too doesn list the fs_meta_max among its parameters.

[James R. Ferguson]

Hi (again) Anar:

> and I suspect the fs_meta_* ones are linked somehow behind the scenes to filecache_* ones.

I suspect that you have deduced things correctly. At the least your observation makes good sense. Good thinking, too.

Regards!

...JRF...

[VK2COT]

Hello,

fs_meta_max is part of Unified File Cache
group of tunable kernel parameters:

filecache_max
filecache_min
fs_meta_max
fs_meta_min

From memory (I am not at my workplace at the moment), fs_meta_max and fs_meta_min are
PRIVATE KERNEL PARAMETERS. They are not
supposed to be "played with" :)

Regards,

VK2COT

[Michal Kapalka (mikap)]

hi,

check this docu :

check this chapter "11.31â s Unified File Cache"

http://h21007.www2.hp.com/portal/download/files/unprot/devresource/Docs/TechPapers/UXPerfCookBook.pdf

did you use something like kcusage ????

mikap

[Anar Veliyev]

As of James' and VK2COT's feedback these four parameters seems are interrelated somehow. And besides the commands below return no lines:
`sed -n '/fs_meta_max=/p;' .bash_history` and
`sed -n '/fs_meta/p;' /var/adm/kc.log`
Which proves to a degree that no manual "intervention" took place towards the fs_meta_* parameters.

Thanks Michal for the link, encountered that book, useful info.
`kcusage fs_meta_max` returns "Unsupported Tunable: ..." message. It didn generate that alike warning log entry in the system.log, if we're after.

The problem we face is rx3600 one behaves and reacts to filecache_* parameters accordingly and immediate reflection is observable through `glance`, but the rx7640 one. It kind of hangs in IO much for the same test load. And warnings in `dmesg` made us to think that "there're some stuff going wrong behind the scenes", though they appear in both servers.

Will dig further.

Grateful for any clue.
Thanks in advance.

[Anar Veliyev]

Seems in fact they're interrelated.
submitted the `kctune filecache_max=1500MB` and `tail -f /var/adm/syslog/syslog.log` yielded the below warning log:
"Jan 4 10:52:32 rx3600_2 vmunix: Warning: The validity of the tunable values could not be completely verified, because the value of the tunable 'fs_meta_max' will not be known until the system is booted. The tunable values will be verified during boot. Please check the console messages during boot to see if there are any tunable value errors."

Besides, as filecache_* attains new value the fs_meta_* too accordingly adjusted by the "invisible hand":
-----------------------------------
[root@rx3600_2:~ ]# kctune filecache_min
Tunable Value Expression Changes
filecache_min 1572864000 1500MB Imm (auto disabled)
[root@rx3600_2:~ ]# kctune filecache_max
Tunable Value Expression Changes
filecache_max 1572864000 1500MB Imm (auto disabled)
[root@rx3600_2:~ ]# kctune fs_meta_min
Tunable Value Expression Changes
fs_meta_min 489291776 Default Auto
[root@rx3600_2:~ ]# kctune fs_meta_max
Tunable Value Expression Changes
fs_meta_max 1467875328 Default Auto
[root@rx3600_2:~ ]# kctune filecache_min=1GB
* The automatic 'backup' configuration has been updated.
* The requested changes have been applied to the currently
running configuration.
Tunable Value Expression Changes
filecache_min (before) 1572864000 1500MB Imm (auto disabled)
(now) 1073741824 1GB
[root@rx3600_2:~ ]# kctune fs_meta_min
Tunable Value Expression Changes
fs_meta_min 326193152 Default Auto
[root@rx3600_2:~ ]# kctune filecache_max=1GB
* The automatic 'backup' configuration has been updated.
* The requested changes have been applied to the currently
running configuration.
Tunable Value Expression Changes
filecache_max (before) 1572864000 1500MB Imm (auto disabled)
(now) 1073741824 1GB
[root@rx3600_2:~ ]# kctune fs_meta_max
Tunable Value Expression Changes
fs_meta_max 978583552 Default Auto
[root@rx3600_2:~ ]#
-----------------------------------

[VK2COT]

Hello,

Yes, fs_meta_max and fs_meta_min are
calculated from filecache_min and filecache_max.

These are not the only private kernel parameters. In fact, there are many of them.

One of the simplest ways to
detect if any of the kernel parameters
were changed from default values (including the private ones), is to run Ignite
command:

# print_manifest

When I teach HP-UX courses, I always warn students to pay attention to that very
useful command. It does not show
all kernel parameters but only those
that were somehow changed from default
values :)

As far as performance problems on your rx7640, go through elimination process.
What causes problems: CPU, I/O, RAM, swap,...

Cheers,

VK2COT

[Anar Veliyev]

Best Regards to all. And grateful for all clues, tips, and info on the subject.