Each file or directory requires an inode, and the object's name lives in a directory rather than in the inode itself. Common metadata operations, such as file creation, lookup, attribute retrieval, rename, enumeration, and deletions can dominate a high file count workload even when data throughput is low. In these scenarios, CPU utilization, serial processing of operations, and network RTT can become bottlenecks to performance. Protocol behavior also matters: NFS and SMB clients can issue different combinations of lookup, open, close, attribute, and directory-read operations that are often protocol version dependent. As a result, different results for similar high file-count workflows can be seen depending on which protocol and protocol version is used.

ONTAP stores public inodes in a hidden, system-managed, volume-level inode file. Each ONTAP 9 inode uses 288 bytes, so the inode file itself consumes usable capacity in the volume. One million allocated public inodes use about 288 MB. Deleting objects frees inodes for reuse, but the inode file does not shrink.

In addition, directory files consume capacity when large numbers of names are stored in the same directory. Those directory files are not part of the inode file. They store names and mappings to inode numbers, and maxdir-size limits each one independently. The 320 MB default setting is a cap, not a reservation; if one directory file grows to 320 MB of directory-file blocks, those blocks use 320 MB of actual volume capacity.

These two structures can add up. At high allocated inode counts, the inode file alone can reach multiple GB, and one or more large directory files can add hundreds of megabytes on top of that. A volume can also have a large inode file with every directory size still small, or one large directory with a still-small inode file. That metadata consumes used volume capacity that is easy to miss if you only look at client-side listings of the user data files. The inode file is not a user-visible file; directory-file size is visible on the directory object itself.

Large directories take longer to enumerate than smaller ones, and a directory that has had many files deleted can still be expensive to scan. The reported directory-file size stays at its high-water mark even after names are deleted. Hole punching on indexed directories can reclaim empty physical blocks and skip them during READDIR, but it does not normally shrink the reported size; see How the maxdir-size cap behaves and Sparse directories and hole punching.

Concentrating millions of entries in one directory creates a single-directory scaling and serialization point that can impact performance not just for the directory itself, but also for the node (or volume) that owns the directory. Distributing files across a multi-directory hierarchy improves parallelism, reduces the scope of directory scans, and makes operational tasks easier.

High object counts can extend namespace scans, backup cataloging, replication, restore processing, and post-restore directory-index construction. For instance, NetApp SnapMirror replicates changed metadata as well as file data, so a baseline or update with many creates, deletes, or renames can be expensive even when the files and capacity footprints are small. These challenges can also extend to NDMP-based backups.

For information on directory-index transfer with SnapMirror, see Directory indexing in ONTAP.

maxdir-size is the per-volume cap on how large any single directory file in that volume can grow. It is presented as a capacity value, rather than a fixed number of entries, even though the number of names in a single directory is one of the factors that can increase directory size. Filename length, Unicode character representation, SMB 8.3 aliases, NFS alternate names, and FlexGroup remote-entry representation all factor into directory size. When you increase the maxdir-size value for a volume, the setting authorizes growth on a per-directory basis rather than preallocating space.

maxfiles (configured as the volume-level option -files) is a configurable ceiling for the number of public inodes available in a single volume. That count includes not just files and directories, but also named streams, ACLs, and other public objects - sometimes objects that are not seen in a regular directory listing. The volume contains a hidden inode file that holds those records. ONTAP grows the inode file when a new public inode is needed and no free record remains, up to the -files setting and total volume size. The configurable maximum for -files depends on volume size and ONTAP limits.