收集或估算：

使用最高水位線值而非每日均值。建置管道、分析作業、移轉和臨時暫存工作流程通常會在短時間內建立最大的命名空間，然後將其清理，但 inode 和目錄檔案在清理後仍可能保留最高水位線標記。

維護兩個分隔的預測：

*請勿從一個值推導出另一個值。*分片命名空間（檔案分割在多個目錄中）可以在不建立大型目錄的情況下耗盡 maxfiles。單一扁平目錄可能會達到 `maxdir-size`限制，而 Volume 仍有數百萬個可用 inode。

*在 NTFS 或大量使用 ACL 的命名空間上，請勿僅根據可見的檔案數量來估算規模 maxfiles。*請將目錄、ACL inode、命名串流及其他公用物件納入您的預估中。在大量使用 ACL 的情況下，請使用高達預估檔案與目錄數量的兩倍作為 `files`的保守初始估算值，然後使用具代表性的資料進行驗證，因為 ACL 共用可以減少實際的使用量。

請參閱 "ONTAP inode 類型" 和 "Maxdir-size 和大型 ONTAP 目錄"。

常見的命名空間佈局有三種。

如果應用程式可以使用寬而深的層級結構，則應盡可能避免將數百萬個名稱放在一個扁平的目錄層級。扁平配置會集中記憶體容量與 CPU 工作，並可能增加大量 GETATTR、 READDIR、尋找與刪除作業期間的延遲。在 FlexGroup Volume 中，大型扁平目錄也可能產生更多遠端項目，導致其目錄檔案比在 FlexVol 中具有相同可見名稱數量的目錄更快接近 maxdir-size。

FlexGroup Volume 通常最適合許多較小的目錄，而不是單一大型扁平目錄。小於約 2 MiB 的目錄會維持在簡單掃描路徑上。從 ONTAP 9.2 開始，較大的目錄會自動建立索引，這有助於目標尋找。建立索引並不會使非常大的目錄等同於分片階層：列舉、萬用字元掃描和單一目錄建立序列化仍然適用。ONTAP 可以將 FlexGroup 子目錄放置在遠端，同時偏好檔案與父目錄的局部性，這可降低這些檔案的遠端延遲。

將檔案分佈在層級結構中意味著使用更多的目錄，每個目錄中的檔案數量更少。

常見的分片鍵包括：

選擇足夠的分片以確保目錄操作可管理的，但不要建立過多近乎空的目錄，以免目錄數量過多。確定性方案使檔案放置可預測，並允許用戶端在無需掃描每個分片的情況下找到檔案。

廣泛和深入的版面配置都可以運作。請將完整路徑長度保持在 NAS 傳輸協定、用戶端作業系統和應用程式的限制範圍內。如果無法避免平面版面配置，請依照"檢視 maxdir-size 和目前目錄大小"所述，監控最大目錄檔案的目前大小和 `maxdir-size`空餘空間，並驗證是否適合進行受控增加。

請勿計畫在 已使用 inode 或最大目錄檔案達到 100% 的情況下進行穩定狀態運作。保留利潤以因應意外成長、暫存物件、Snapshot 快照技術保留的中繼資料、ACL 與串流、移轉重疊、備份工作、FlexGroup 放置不平衡，以及會變更檔案名稱的軟體變更。

將 files`設定為目前最大值是一個上限，而不是執行直到最後一個 inode 消失的權限。應在遠低於該上限之前對 `files-used`發出警報。對於 `maxdir-size，在 "當超出 maxdir-size 時會發生什麼事？" 中大約 2% 的增加指導原則是指如何提高上限，而不是通用的運作利潤。

分別對 inode 檔案、目錄檔案、索引、Snapshot 快照技術和彙總中繼資料進行預算。每個已分配的公共 inode 使用 288 位元組作為 inode 檔案的基本估算值；請參閱 "容量影響"。提高 `files`並不會立即分配該空間。將峰值已分配的 inode 檔案容量視為持久容量。

使用 `volume show-space`來檢查 inode 和中繼資料容量，而不是將每個 CLI 計數器都當作位元組值來轉換。

至少測試：

路徑長度和基本名稱長度不可互換。跨越多個目錄的長路徑會影響協定限制和 inode 計數，而每個目錄僅儲存其立即組成部分。

順序頻寬測試無法預測高檔案數量下的效能表現。包括：

測量延遲分佈、CPU、快取行為、網路負載和完成時間。如果 Snapshot 快照技術、複寫、分析、備份和安全性掃描等作業在生產環境中同時存在，則在這些作業期間重複測試。

測試超出初始擷取的情況：

目錄索引可能需要在目的地建置或傳輸。僅當避免重建能顯著改善恢復時，才啟用公用索引傳輸；它不會改善本機查閱。請參閱 "何時啟用公共目錄索引傳輸"。

依照 "監控 maxfiles、EMS 事件和 ONTAP 增強功能" 中所述、追蹤 files-used（相對於 files 和 inodefile-public-capacity）。在 files-used 達到 files 之前發出警示。對於 FlexGroup Volume、即使整體總量看似仍有空間、也應調查組成成員層級的事件。

測量目錄檔案大小並解析 EMS 檔案 ID，如 "檢視 maxdir-size 和目前目錄大小" 所述。在已知扁平目錄或頻繁變更的目錄產生警告之前，先對其進行清點。

關於 inode 警告：

關於目錄大小警告：

請勿等待 callhome.no.inodes`或 `wafl.dir.size.max；此時用戶端建立作業已經失敗。

刪除檔案會釋放公共 inode 以供重複使用，但不會縮小公共 inode 檔案。同樣地，從目錄中刪除名稱會使目錄插槽可重複使用，但通常不會減少目錄檔案的最高水位大小。

大型刪除操作會佔用大量中繼資料，並可能暫時增加私人殭屍 inode 的數量。當用戶端側遞迴刪除 (rm -rf）與生產流量競爭時，應限制其速率。

從 ONTAP 9.8 開始， volume file async-delete 會從叢集移除目錄，而不是透過 NFS 或 SMB，這可避免用戶端與網路爭用。這適用於 FlexVol 與 FlexGroup Volume。ONTAP 掃描路徑，先刪除子目錄內容，並執行平行刪除工作（預設 5,000 個並行工作；可設定為 50 到 100,000 個）。在 TR-4571 測試中，對於 24,000 個項目的樹狀結構，這比單一執行緒 `rm -rf`快約 10 倍。

限制條件：Volume 必須處於線上並已裝載，路徑必須是一個目錄（而不是單一檔案），並且一次只能執行一個 async-delete 作業。

如果大型稀疏目錄仍然存在問題，請將剩餘項目製作複本到新目錄中。降低 `maxdir-size`並不會將其壓縮。請參閱 "稀疏目錄和打孔"。

即使資料處理量較低，高檔案數操作仍會使用 CPU、記憶體容量、快取和儲存設備 I/O。保留餘裕以供：

應根據觀察到的中繼資料需求（而不僅僅是容量或處理量）來平衡工作負載。即使網路和磁碟頻寬看似可用，節點仍可能因中繼資料而受限。

高檔案數的 NAS 通常受限於中繼資料。NFS 或 SMB 裝載通常使用一個 TCP 連線連接到一個資料 LIF，而該 LIF 位於一個節點上。如果許多用戶端、掃描器或備份作業裝載同一個位址，即使叢集的其餘部分處於閒置狀態，該節點也會將 CPU 用於協定處理。FlexGroup 可以透過叢集網路重新導向檔案作業，但這並不會移除擁有用戶端連線之節點上的負載。

支援 NFS nconnect 或 SMB 多通道的單一用戶端可以在一個裝載上開啟額外的連線。這有利於該用戶端；但這並不能取代將許多用戶端分散在各個 LIF 和節點上的做法。

ONTAP 的後續版本包括目錄索引、inode 管理改進、稀疏目錄最佳化、目錄索引傳輸以及其他針對高檔案數處理的增強功能。升級決策仍需考慮平台支援、資料保護相容性和應用程式資格判斷。

請勿僅因為某項功能與高檔案數量有關而啟用它：

從 ONTAP 9.17.1 開始，在新建的 NAS SVM 中，新 Volume 可以預設啟用檔案系統分析。請檢查 -analytics-state 而不是假設它已停用，並在對高檔案數工作負載進行資格判斷時，將其命名空間掃描納入帳戶。

記錄：

當應用程式版本、檔案名稱格式、保留、協定或資料保護工作流程發生變更時，請重新審視模型。