Common Misconfigured HP-UX Resources (April 2006)

JFS Inode
Free List
inode inode inode
inode inode
inode
inode inode
JFS uses a number of factors to determine the number of free lists on the system, such number of
inodes, maximum number of processors supported, etc. The number of free lists is not tunable and
can vary from one JFS version to the next. The number of free lists can be identified with the
following adb command:
# echo “vx_nfreelists/D” | adb –k /stand/vmunix /dev/mem # 11.11
# echo “vx_nfreelists/D” | adb –o /stand/vmunix /dev/kmem # 11.23
More discussion on how the free lists affect memory utilization will follow.
Growing the JFS Inode Cache
When a file is opened or accessed and it does not already exist in the cache, its inode must be
brought in from disk into the JFS inode cache. JFS must make a decision as to whether to use one of
the existing inodes on a free list, or to allocate a new inode if you have not allocated the maximum
number of inodes. For JFS 3.3 and later, an inode must be on a free list for three minutes before it is
reused. If the inodes on the free list have been there for less than two or three minutes, then JFS will
allocate more inodes from the kernel memory allocator as necessary.
Consider an application that does a stat system call on many files in a very short timeframe.
Example applications or processes are the find, ls, ll, or backup commands. These commands
traverse through the file systems at a very rapid pace. If you have enough files on your system, you
can easily fill up the JFS inode cache in a very short time. However, the files are usually not kept
open. Therefore, if the JFS inode cache fills up, an inode is claimed off the free list even though it has
not been on the free list for the appropriate amount of time.
Note that maintaining all these inodes may or may not be helpful. For example, if the inode cache
can hold 128,000 inodes, and the find(1) command traverses 129,000 inodes, then only the last
19