每个文件或目录都需要一个 inode，并且对象的名称位于目录中，而不是 inode 本身。常见的元数据操作（如文件创建、查找、属性检索、重命名、枚举和删除）即使在数据吞吐量较低的情况下，也可能主导高文件计数工作负载。在这些情况下，CPU 利用率、操作的串行处理和网络 RTT 可能成为性能瓶颈。协议行为也很重要：NFS 和 SMB 客户端可以发出查找、打开、关闭、属性和目录读取操作的不同组合，这些操作通常取决于协议版本。因此，根据所使用的协议和协议版本，类似的高文件计数工作流可能会产生不同的结果。

ONTAP 将公共 inode 存储在隐藏的、系统管理的卷级 inode 文件中。每个 ONTAP 9 inode 使用 288 个字节，因此 inode 文件本身消耗卷的可用容量。100 万个已分配的公共 inode 使用约 288 MB。删除对象将释放 inode 以供重用，但 inode 文件不会收缩。

此外，当大量名称存储在同一目录中时，目录文件会消耗容量。这些目录文件不是 inode 文件的一部分。它们存储名称及其到 inode 编号的映射，并 `maxdir-size`对每个目录文件单独进行限制。320 MB 的默认设置是上限，而非预留空间；如果一个目录文件增长到 320 MB 的目录文件块，这些块将使用 320 MB 的实际卷容量。

这两个结构可以叠加。在 inode 分配数量较高时，仅 inode 文件本身就可能达到数 GB，而一个或多个大型目录文件还可能在此基础上增加数百 MB。卷也可以拥有一个大型 inode 文件，而每个目录大小仍然很小；或者拥有一个大型目录，而 inode 文件仍然很小。如果仅查看用户数据文件的客户端列表，则该元数据所占用的卷容量很容易被忽略。inode 文件不是用户可见的文件；目录文件大小在目录对象本身上可见。

较大的目录比较小的目录需要更长的时间来枚举，已删除许多文件的目录的扫描成本仍然很高。即使在名称被删除后，报告的目录文件大小仍保持在高水位线。对索引目录进行打孔操作可以回收空的物理块，并在 `READDIR`期间跳过这些块，但通常不会缩小报告的大小；请参阅"maxdir-size 上限的行为方式"和"稀疏目录和打孔"。

将数百万个条目集中在一个目录中会创建一个单目录扩展和序列化点，这不仅会影响目录本身的性能，还会影响拥有该目录的节点（或卷）的性能。在多目录层次结构中分发文件可以提高并行性，减少目录扫描的范围，并使操作任务更轻松。

高对象计数可以延长命名空间扫描、备份编目、复制、还原处理和还原后目录索引构建。例如，NetApp SnapMirror 复制更改的元数据以及文件数据，因此即使文件和容量占用空间很小，包含大量创建、删除或重命名操作的基线或更新也可能代价高昂。这些挑战也可能延伸到基于 NDMP 的备份。

有关使用 SnapMirror 进行目录索引传输的信息，请参见 "ONTAP 中的目录索引"。

maxfiles （配置为卷级选项 -files）是单个卷中可用的公共 inode 数量的可配置上限。该计数不仅包括文件和目录，还包括命名流、ACL 和其他公共对象——有时是在常规目录列表中看不到的对象。卷包含一个隐藏的 inode 文件，该文件保存这些记录。当需要新的公共 inode 且没有剩余空闲记录时，ONTAP 会扩展 inode 文件，直至达到 `-files`设置和总卷大小的限制。 `-files`的可配置最大值取决于卷大小和 ONTAP 限制。