每個檔案或目錄都需要一個 inode，而物件的名稱是存在於目錄中，而非 inode 本身。即使資料處理量很低，常見的中繼資料操作（例如檔案建立、尋找、屬性擷取、重新命名、列舉和刪除）也可能在檔案數量龐大的工作負載中佔據主導地位。在這些情況下，CPU 使用率、操作的序列處理以及網路 RTT 都可能成為效能的瓶頸。傳輸協定行為也很重要：NFS 和 SMB 用戶端可以發出不同的尋找、開啟、結案、屬性及目錄讀取操作組合，這些操作通常取決於傳輸協定版本。因此，對於類似的大量檔案工作流程，根據所使用的傳輸協定和傳輸協定版本，可能會出現不同的結果。

ONTAP 將公用 inode 儲存在隱藏、系統管理的 Volume 層級 inode 檔案中。每個 ONTAP 9 inode 使用 288 位元組，因此 inode 檔案本身會使用 Volume 中的可用容量。一百萬個已配置的公用 inode 大約使用 288 MB。刪除物件會釋放 inode 以供重複使用，但 inode 檔案不會縮小。

此外，當大量名稱儲存在同一個目錄中時，目錄檔案會使用容量。這些目錄檔案不屬於 inode 檔案。它們儲存名稱以及對應至 inode 編號的對應關係，而且 maxdir-size 會獨立限制每一個目錄檔案。320 MB 的預設設定是一個上限，而不是預留；如果一個目錄檔案成長到 320 MB 的目錄檔案區塊，這些區塊將使用 320 MB 的實際 Volume 容量。

這兩種結構加起來會佔用大量空間。在分配的 inode 數量較高的情況下，僅 inode 檔案本身可能達到數 GB，而一個或多個大型目錄檔案也會在此基礎上增加數百 MB。一個 Volume 也可能包含一個很大的 inode 檔案，但每個目錄的大小仍然很小；或者一個很大的目錄，但其 inode 檔案卻很小。這些中繼資料會使用已使用的 Volume 容量，如果您只查看用戶端側的使用者資料檔案清單，很容易忽略這一點。inode 檔案不是使用者可見的檔案；目錄檔案的大小在目錄物件本身上是可見的。

列舉大型目錄所需的時間比小型目錄更長，而且刪除了許多檔案的目錄，掃描成本仍然可能很高。即使刪除了名稱，報告的目錄檔案大小仍然保持在其高水位標記。對已索引目錄進行打洞可以回收空的實體區塊，並在 READDIR 期間跳過它們，但這通常不會縮小報告的大小；請參閱 "maxdir-size 上限的行為方式" 和 "稀疏目錄和打孔"。

將數百萬個條目集中在一個目錄中會造成單一目錄擴充和序列化點，這不僅會影響目錄本身的效能，還會影響擁有該目錄的節點（或 Volume）的效能。將檔案分佈在多目錄階層中可以提高並行性，減少目錄掃描範圍，並簡化操作任務。

物件數量過多會延長命名空間掃描、備份編目、複寫、還原處理以及還原後目錄索引建置的時間。例如，NetApp SnapMirror 會複寫變更的中繼資料以及檔案資料，因此，即使檔案和容量佔用空間很小，包含大量建立、刪除或重新命名操作的基線或更新也可能會耗費大量資源。這些挑戰也可能延伸至架構於 NDMP 的備份。

如需使用 SnapMirror 進行目錄索引傳輸的相關資訊，請參閱 "ONTAP 中的目錄索引"。

maxfiles（設定為 Volume 層級選項 -files）是單一 Volume 中可用公用 inode 數量的可設定上限。該計數不僅包括檔案和目錄，還包括命名串流、 ACL 和其他公用物件——有時甚至是常規目錄清單中看不到的物件。Volume 包含一個隱藏的 inode 檔案來保存這些記錄。當需要新的公用 inode 且沒有剩餘的可用記錄時， ONTAP 會擴展 inode 檔案，直到達到 `-files`設定與 Volume 總大小。 `-files`的可設定最大值取決於 Volume 大小與 ONTAP 限制。