ONTAP uses inodes to track file-system objects. You can monitor public inode use with the following volume values in the CLI, REST API, or System Manager:

The files option controls how many public inode entries may be allocated in the public inode file. Increasing the files limit does not immediately allocate inodes or inode-file space to the active file system. Instead, it sets the upper limit allowed by the volume.

Creating files, directories, ACLs, named streams, or public directory indexes can grow the public inode file. Deleting objects decreases files-used and returns public inodes for reuse, but it does not shrink the public inode file's size.

For examples of how to view file-count usage details, see Monitoring example. For sizing guidance, see High-file-count NAS workload best practices.

Not all inodes count against the public inode limit. Private inodes do not. Public inodes such as files, directories, ACLs, named streams, and public directory indexes do.

files-used increases whenever a public inode is taken for use. If a free public inode already exists in the allocated inode file, files-used still increases, but inodefile-public-capacity does not. If no free public inode remains, ONTAP grows the public inode file up to files, and both values increase.

Typical operations include:

How those object types, ACL sharing, and streams such as Zone.Identifier affect visible file count is described in ONTAP inode types.

files-used decreases when public inodes become free, such as after deletion completes and the objects are no longer retained as zombies. inodefile-public-capacity remains at its high-water mark and the inode file size never decreases.

New creates reuse free records until the allocated inode file is full, after which ONTAP grows it if files and volume capacity permit.

High file counts increase the proportion of metadata work relative to data transfer. Common operations include:

The performance effect depends on operation rate, concurrency, protocol behavior, namespace layout, cache state, and node resources. Total file count alone is not a performance forecast. Millions of files spread across many active directories can expose more parallelism than the same file count concentrated in a single directory space.

Each ONTAP 9 inode occupies 288 bytes in the inode file. A planning approximation is:

These figures describe inode records. Observed physical usage can also include inode-file structure, block rounding, Snapshot retention, and other metadata.

Raising files changes the permitted ceiling; it does not immediately allocate all corresponding inode-file space. Capacity is consumed as the inode file grows. If it later holds one million public inodes, the raw inode records use 288 MB (approximately 274.7 MiB) of actual volume capacity. The inode file does not shrink, so capacity planning must account for its historical high-water allocation. You can later lower files, but not below inodefile-public-capacity. That field is the allocated inode-file high-water mark, not peak files-used and not a previous files setting. For example, if the inode file has already grown to 1 million records, files cannot be set below 1 million even if current files-used is much lower. If you raised files without growing the inode file that far, you can lower it again down to the current capacity.

Used physical capacity for the inode file is separate from maxdir-size used capacity. maxdir-size caps the byte size of each directory's name-mapping file. A 320 MB directory file uses 320 MB of directory-file blocks in that directory; a similarly sized inode file represents the volume-wide inode population and is not limited by maxdir-size.

For how to inspect inode-file space in capacity units and how to read inodefile-public-capacity as an inode count, see Monitor maxfiles, EMS events, and ONTAP enhancements.