Ability to flush / clear the cache (not to disk)

Due to processing by IBM, this request was reassigned to have the following updated attributes:
Brand - Servers and Systems Software
Product family - IBM Spectrum Scale
Product - Spectrum Scale (formerly known as GPFS) - Private RFEs
Component - Product functionality

For recording keeping, the previous attributes were:
Brand - Servers and Systems Software
Product family - IBM Spectrum Scale
Product - Spectrum Scale (formerly known as GPFS) - Private RFEs
Component - V3 Product functionality

The interactions between the various levels of cache provided by Scale make it extremely difficult to know if a node's cache can be safely cleared. Any method that is both safe and effective is going to end being about as heavyweight as umount.

In the case of GPFS running on Linux, "cache" can mean several different things. There's GPFS pagepool, GPFS OpenFile objects, GPFS CompactOpenFile objects, GPFS tokens (cached client-side and server-side), Linux kernel inode objects, Linux kernel name cache (dcache objects), and Linux kernel pagecache, to name the most important ones. There are complex dependencies between those different cache object types. In general, it is not possible to throw our an arbitrary object out of cache unless the file system access has been completely quiesced. For example, if a dentry is in use (e.g. because some process is using the corresponding directory as the current working dir), that dentry can't be thrown out, and the corresponding struct inode is referenced as well, and can't be thrown out, and the corresponding GPFS OpenFile object can't be thrown out, because we can't have a kernel struct inode that's not backed by a GPFS cache object. If a file is mmap'ed, the caching situation is particularly convoluted (in short, nothing can be thrown out of cache without risking deadlocks). So the task of "clearing the cache" is a very messy one. The need for a cache clearing/invalidation tool that's less heavy-weight than umount has come up before. The typical rationale is a need to run a benchmark. Unfortunately, for the purposes of getting a clean slate for a benchmark run, a partial cache invalidation is not a good idea, since it could lead to misleading results. However, if a full cache invalidation is needed, the file system must be not referenced in any way (no open files, no cwd references, etc). If this is the case though, running umount wouldn't be problematic. If umount fails because the file system is busy, then some references are present, and a full cache clear-out wouldn't be possible. Implementing a "best effort" partial cache clear-out tool isn't useful enough to justify the cost.

Due to processing by IBM, this request was reassigned to have the following updated attributes:
Brand - Servers and Systems Software
Product family - General Parallel File System
Product - GPFS
Component - V3 Product functionality
Operating system - Multiple

For recording keeping, the previous attributes were:
Brand - Servers and Systems Software
Product family - General Parallel File System
Product - GPFS
Component - V3
Operating system - Multiple

Creating a new RFE based on Community RFE #56767 in product GPFS.