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 no 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 node). A stat cache entry consumes significantly less memory than a full inode. Stat cache entries are kept for the following:
  • Recently accessed files
  • Directories recently accessed by a number of stat() calls
To set the value of the stat cache, use the maxStatCache attribute of the mmchconfig command.
Notes:
  1. GPFS prefetches data for stat cache entries if a pattern of use indicates this is productive (for example, if a number of ls -l commands issued for a large directory).

  2. In versions of IBM Storage Scale earlier than 5.0.2, the stat cache is not effective on the Linux® platform unless the Local Read-Only Cache (LROC) is configured. For more information, see the description of the maxStatCache parameter in the topic mmchconfig command. The size of the GPFS shared segment can limit the maximum setting of maxStatCache.

  3. 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
  4. Depending on the usage pattern, system performance might 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.