Non-pinned memory

There are two levels of cache used to store file metadata.

Inode cache

The inode cache contains copies of inodes for open files and for some recently used files that are no longer open. The maxFilesToCache parameter controls the number of inodes cached by GPFS™. Every open file on a node consumes a space in the inode cache. Additional space in the inode cache is used to store the inodes for recently used files in case another application needs that data.

The number of open files can exceed the value defined by the maxFilesToCache parameter to enable applications to operate. However, when the maxFilesToCache number is exceeded, there is not more caching of recently open files, and only open file inode data is kept in the cache.

Stat cache

The stat cache contains enough information to respond to inquiries about the file and open it, but not enough information to read from it or write to it. There is sufficient data from the inode in the stat cache to respond to a stat() call (for example, when issuing the ls -l command on a UNIX or Linux node). A stat cache entry consumes significantly less memory than a full inode. The default value stat cache is four times the maxFilesToCache parameter. This value may be changed through the maxStatCache parameter on the mmchconfig command. Stat cache entries are kept for the following:

• Recently accessed files
• Directories recently accessed by a number of stat() calls

Notes:

1. GPFS prefetches data for stat cache entries if a pattern of use indicates this will be productive (for example, if a number of ls -l commands issued for a large directory).
2. Each entry in the inode cache and the stat cache requires appropriate tokens:
   1. To ensure the cached information remains correct
   2. For the storage of tokens on the file system manager node
3. Depending on the usage pattern, system performance may degrade when an information update requires revoking a token. This happens when two or more nodes share the same information and the most recent information is moved to a different location. When the current node needs to access the updated information, the token manager must revoke the token from the current node before that node can access the information in the new location.