変更する `maxdir-size`設定自体は容量を消費しません。ディレクトリのエントリ数の増加はそれにつながります。ディレクトリファイルは、名前が追加されるたびに 4 KiB のブロックを割り当てます。付随するインデックスと Snapshot に保持されるディレクトリブロックは、さらに多くのブロックを追加します。上限を設定しても、そのスペースは予約されません。削除後の高水位サイズについては、"maxdir-size の上限値の動作について"を参照してください。

値を見積もる際 maxdir-size、ディレクトリ配下のファイルに格納されているデータを含める必要はありません。代わりに、単一のディレクトリ内のエントリのみを考慮してください。このオプションはボリュームレベルで設定されますが、ディレクトリごとに適用されます。

ファイル数の多いディレクトリの容量使用量を計画する際には、ディレクトリとインデックスのオーバーヘッドも考慮に入れる必要があります。例えば、それぞれが320 MBの上限まで成長する100個のディレクトリを含むボリュームには、約32 GBのディレクトリファイルメタデータが格納され、これはボリュームの使用容量にカウントされます。それらのディレクトリがインデックス化されていて公開されている場合は、maxfiles の予算に約100個の inode を追加してください。ディレクトリのメタデータが頻繁に更新される場合は、Snapshotコピーには置き換えられたディレクトリおよびインデックスブロックが保持されるため、追加の Snapshot 容量を考慮してください。

ONTAP システム内の大きなディレクトリは、以下に影響を与える可能性があります：

ディレクトリインデックスはターゲット検索のコストを削減しますが、非常に大きなフラットディレクトリをシャーディングされた階層構造と同等にするものではありません。周囲のボリュームやクラスタに未使用のリソースがある場合でも、単一のディレクトリに対する操作では、シリアル化やアフィニティの制限が発生する可能性があります。インデックス作成は、検索、オープン、作成、名前変更、削除といった、特定の名前に対する操作を容易にします。ディレクトリ全体のスキャンとワイルドカード検索は、引き続きディレクトリの名前空間を走査します。インデックスを名前からブロックへのショートカットとして使用しません。ホールパンチされたディレクトリでは、インデックスは `READDIR`の際に空のブロックをスキップできますが、それはシャーディングされたレイアウトの代替にはなりません。

ONTAPがパフォーマンス障害を宣言する、個別のディレクトリファイルサイズのしきい値は存在しません。約 2 MiB のインデックスしきい値（"ディレクトリインデックスが存在する理由"で説明）は、ターゲット検索の提供方法を変更します。そのサイズ以下では、名前の検索においてディレクトリブロックをスキャンして一時的なインメモリハッシュを構築できるため、コストはディレクトリのサイズとともに増加しますが、ONTAP は永続的なインデックスを作成しません。そのサイズを超えると、ターゲットを絞った名前操作にはインデックスが使用されます。ディレクトリが大きくなるにつれてコストが上昇し続けるのは、完全な列挙とワイルドカード検索、ディレクトリおよびインデックスブロックのコールドキャッシュロード、ならびにそのディレクトリに対する操作のシリアライゼーションです。

クライアントは、より長いディレクトリ一覧、ワイルドカード検索、アプリケーションスキャン、より高いプロトコル遅延、およびそれらの操作中のタイムアウトが発生する可能性があります。ディレクトリを所有するノードは、データスループットが低いまま、メタデータにCPUとメモリを費やす可能性があります。その影響は、操作速度、同時実行性、キャッシュの状態、およびそのディレクトリに集中している名前の数によって異なります。 wafl.dir.size.warning、通常は `maxdir-size`の約90%で、ディレクトリのサイズが上限に近づいていることを警告します。これは、測定された遅延しきい値を示すものではありません。

例えば、そのディレクトリ内の既知のファイルを1つ開く場合、インデックスが名前検索の役割を果たすため、すぐに結果が返ってくる可能性があります。同じディレクトリを `ls`で一覧表示したり、 `find`でウォークしたり、すべての名前を読み取るアプリケーション、バックアップ、またはセキュリティスキャンを実行すると、長時間実行されたり、ハングアップしたように見えたり、クライアントまたはアプリケーションのタイムアウトが発生したりする可能性があります。その間、クライアントはごくわずかなファイルデータしか転送しません。既に開いているファイルの読み書きは、通常影響を受けません。

ワークロードがより大きな単一ディレクトリを必要とし、かつ再構築が現実的でない場合にのみ `maxdir-size`を上げてください。アプリケーションが許容する場合は、幅の広い階層構造または深い階層構造を優先してください。

ディレクトリファイルが上限に達した場合：

フラットな名前空間を変更できない場合は、制御された `maxdir-size`増加を評価します：

平均的な成長率を目指す場合、現在の上限を約2%ずつ増額してください。既知の測定要件がある移行の場合、上限値をその要件の約2%上に設定してください。変更は即座に行われ、無停止で実施されます。

後で上限値を下げることはできますが、既存のディレクトリファイルの最大サイズを下回ることはできません。上限値を下げても、既存のディレクトリは圧縮されません。ONTAPリリースとプラットフォームでサポートされている値を確認し、変更後のパフォーマンスを監視してください。