Skip to main content
ONTAP Technical Reports
日本語は機械翻訳による参考訳です。内容に矛盾や不一致があった場合には、英語の内容が優先されます。

Maxdir-size と large ONTAP ディレクトリ

共同作成者 whyistheinternetbroken

`maxdir-size`は、そのディレクトリ内の名前に割り当て可能な容量を制限することで、ONTAPボリューム内の各ディレクトリファイルのサイズを制限します。これはボリュームの `maxfiles`inode制限とは独立しており、単一ディレクトリ内の名前の数に静的に定義可能な制限はありません。これは、その値が可変であり、名前の長さや文字の種類など、多くの要因に基づいているためです。詳細については、"ディレクトリファイルあたりの名前の数を推定する"を参照してください。

ONTAPにおけるディレクトリとは何ですか?

WAFL ディレクトリは、名前を inode 番号にマッピングするメタデータファイルです。そのサイズは、そのディレクトリ以下のファイルに保存されているデータの合計ではなく、ディレクトリに格納されているファイル名の数と、それぞれの名前が必要とするディレクトリ容量によって決まります。新しく作成されたディレクトリは 4 KiB から始まり、エントリが追加されるにつれて 4 KiB のディレクトリブロック単位でサイズが大きくなります。

このディレクトリは1つのinodeを消費し、そのレコードはボリュームレベルのinodeファイル(概念的にも機能的にも別個のファイル)に格納されます。ディレクトリ名は、そのディレクトリ自身のデータブロックに格納されます。名前を追加すると個々のディレクトリファイルのサイズが大きくなり、 `maxdir-size`の制限に近づく可能性があります。また、より多くのファイルシステムオブジェクト(ファイル、ディレクトリ、ACL、名前付きストリームなど)を作成すると、より多くのinodeレコードが割り当てられ、ボリュームレベルのinodeファイルが `maxfiles`の制限に向かって拡張される可能性があります。単一の4KiBディレクトリブロックに格納できる名前エントリの数は、各名前の格納方法によって決まり、格納方法は名前の長さと文字エンコーディングによって異なります。

ディレクトリブロックのレイアウト

ONTAPディレクトリファイルは4 KiBのブロック単位で拡張され、各ブロックは、それぞれのサイズに基づいて可変数のエントリレコードと名前チャンクに制限されます。ONTAPの名前チャンクは、ファイル名の一部を格納する16バイトのスロットです。各ファイル名は1つのエントリレコードと、エンコードされた長さに必要な数の16バイトのチャンクを占有します。

48バイトの名前に対して、名前のチャンクがどのように割り当てられるかの例:

48バイトのファイル名を、16バイトの名前チャンク3つと16バイトのUnicode短縮形式のオーバーヘッドチャンク1つとして格納した図

ディレクトリブロックの最大数と名前の最大数

ディレクトリブロックの最大許容数は、 `maxdir-size`の値によって決まります。

320 MB のディレクトリサイズでは、最大 81,920 個のディレクトリブロックを割り当てることができます (320 MB / 4 KiB、ここで 320 MB は 335,544,320 バイトです。これは ONTAP がこれらの値をバイナリ単位で報告するためです)。したがって、ディレクトリファイルで許可される名前の総数は、ディレクトリブロックごとに許可されるエントリ数によって決まります。

ディレクトリブロックの構築方法

4 KiB のディレクトリブロックはすべて同じように分割されます:

  • 最大128件のエントリレコード(各レコード12バイト、合計1536バイト)

  • 16バイトずつの160個の名前チャンク(合計2560バイト)からなる共有プール

これらを合わせると、4 KiB のブロック1つを占めます。保存される各名前には、エントリレコードと1つ以上の名前チャンクが必要であり、128個のエントリレコードまたは160個の名前チャンクのどちらかが先に枯渇した方によって、そのブロックに格納できる名前の数が決まります。ASCII文字を使った名前の場合、名前のチャンクが最初に使い切られます。その結果、 `maxdir-size / filename-length`も1メガバイトあたりのファイル数の固定比率も正確ではありません。

下の図は、前の例で示した48バイトの名前を示しています。その1つの名前は、12バイトのエントリレコード1つと、先に示した4つの16バイトの名前チャンク(合計64バイト)を消費します。

4 KiB のディレクトリブロックの図。1 つの 12 バイトのエントリレコードと 4 つの 16 バイトの名前チャンクを使用した、48 バイトの Unicode 短縮名を示す。

 

160個のチャンクからなるプールは、エントリレコードが消費される前にブロック内の空き容量が不足します。合計160個のチャンク / 4個のチャンクで、1ブロックあたり40個の名前になります。あるいは、128件のエントリレコードのうち88件は未使用のままとなります。より短い日常的な名前であれば、必要なチャンクは3つだけで済むため、同じ4 KiBのディレクトリブロックには、そのような名前を約53個格納できます。これは、名前のサイズが、単一のディレクトリで許可される名前の数に直接影響を与えることを示しています。

ディレクトリファイルあたりの名前の数を推定する

1つのディレクトリにいくつの名前が収まるかを概算するには、まず4 KiBのブロック1つにいくつの名前が収まるかを計算し、次にその数に上限で許可されているブロック数を掛けます。(320 MBの上限では、81,920ブロックになります。)

1つのブロックにいくつの名前が収まるかは、それぞれの名前がブロック内のスペースをどれだけ占めるかによって決まります。短くてシンプルな名前はスペースをあまり取らないため、より多くの名前が収まります。長い名前、またはONTAPがより広い形式で保存する必要がある名前は、より多くのスペースを占有するため、収まる名前の数が少なくなります:

  • 日常的な名前は最大約32文字(例: report-2026.csv)はすべて同じようにパックされ、1つのブロックに約53個入ります。

  • 名前が長くなるほど、1ブロックあたりに収まる数は少なくなります。例えば、48文字の名前の場合、1ブロックあたり約40個しか収まりません。

  • より広い形式で保存する必要のある名前は、およそ2倍のスペースを必要とするため、保存できる名前の数は少なくなります。これは、非ASCII文字(アクセント付きテキストや東アジアのテキストなど)を含む名前、NFS代替名も持つ名前、およびFlexGroupリモートエントリーに適用されます。この種の32文字の名前は、特殊文字に必要なサイズのため、1ブロックあたり約26個しか収まりません。SMBが長い名前の他に短い「8.3」エイリアスも生成する場合、そのエイリアスも余分なスペースを消費します。

従来のDOSスタイルの「8.3」という名前を格納する古いボリュームは、これらの名前が非常に小さい(バイト数が少ない)ため、1ブロックあたり最大128個のエントリを格納できます。ただし、通常の名前を持つ最新のボリュームでは、このような動作は発生しません。これは、現在のONTAPボリュームがファイル名をUnicode形式(デフォルトではC.UTF-8)で保存するためです。これにより、はるかに古いシステムが依存していた8文字のDOSスタイルの名前とは異なり、NFSやSMBを介して長いファイル名や国際文字をサポートできます。ボリューム言語の詳細については、<insert link here>を参照してください。

ファイル名は非常に多様なので、ディレクトリ内に保存できるファイル数に決まった上限はありません。有用な計画数値は、FlexVol volume の 320 MB 設定で約 430 万の通常名です。ここでいう「通常の名前」とは、ASCII 文字で約 32 文字までのものを指します。これはあくまで大まかな例であり、保証するものではありません。また、名前の長さに特定の条件があるわけでもありません。下の表は、いくつかの一般的なケースと、320 MB の設定で 1 つのディレクトリ内にそれぞれ許容される名前のおおよその数を示しています。

名前プロフィール サンプルファイル名 4 KiBブロックあたりの名前数 1つのディレクトリ内のファイル名(320 MB)

短くて普段使いしやすい名前(8文字)

f0001.db

53

4,341,758

日常的な名前(32文字)

project-alpha-run0142-input1.dat

53

4,341,758

長い名前(48文字)

run-2026-09-21-node07-sensor-array-01423.parquet

40

3,276,798

非ASCII文字を含む名前、またはFlexGroupエントリ(32文字)

résumé-final-2026-09-21-v03.docx

26

2,129,918

NFS代替名も持つ名前(32文字)

Marketing-Overview-2026Q3v2.pptx`代替案付き `MARKET~1.PPT

22

1,802,238

注: カウントは、 `.`および `..`のエントリが存在することを前提としており、そのため各値は計算結果よりもわずかに小さくなっています。

要約すると、同じ320MBの容量制限では、短くて日常的な名前であれば約430万件まで保存できますが、名前をより広い形式で保存する場合は、その半分以下の数しか保存できません。すべての名前がプロトコルの最大文字数である255文字までだとすると、約73万7,000個の名前しか許可されません。

ファイル名の長さとパスの長さの比較

`maxdir-size`特定の親ディレクトリに格納されているベース名を表します。エントリごとに完全な絶対パスを保存するわけではありません。各パス名コンポーネントは、それぞれ独自の親ディレクトリ内のエントリです。そのため、より深いディレクトリ構造では `maxdir-size`の使用量は増加しません。

階層構造を深くすると、ボリューム内にディレクトリとパブリックiノードが追加されますが、各ディレクトリに格納される名前の数は減少します。このトレードオフは通常、拡張性と全体的なパフォーマンスを向上させます。

注: プロトコルとクライアントのパス長制限はそれぞれ独立して適用されます。

maxdir-size の上限値の動作について

この上限はボリューム内のすべてのディレクトリに個別に適用され、予約ではなく制限です。320 MBという設定は、即座に320 MBのボリューム容量を確保するものではなく、単に任意のディレクトリがそのサイズまで拡張できるようにするものです。

以下に、考慮すべき事項をいくつか挙げます。

  • ディレクトリファイルが320MBのブロックにまで拡張した場合、それらのブロックは320MBの実際のボリューム容量を使用します。

  • ディレクトリファイルが一度大きくなると、後でエントリが削除されたとしても、そのサイズは最大サイズのまま維持されます。

  • ファイルやディレクトリを削除すると、それらのエントリスロットは再利用可能になりますが、ディレクトリファイルは圧縮されません。

  • インデックス付きディレクトリは、完全に空の 4 KiB ブロックにホールパンチを実行し(ONTAP 9.5 以降で使用可能)、ディスク上の物理ブロックを解放できますが、報告されるディレクトリファイルのサイズは通常縮小しません。

注: ONTAPが大規模ディレクトリ用に作成する付属のディレクトリインデックスは、独自のメタデータ容量とinodeを消費しますが、ディレクトリファイルの一部ではなく、 maxdir-size`のカウント対象にはなりません。インデックスがSnapMirrorレプリケーション目的でパブリックinodeスペースを占有するように設定されている場合は、代わりに `maxfiles(パブリックinode制限)のカウント対象となります。

詳細については、"ONTAPのディレクトリインデックス作成"を参照してください。

maxdir-sizeの値を上げる

  • ボリューム内のすべてのディレクトリに適用されます

  • ディレクトリファイルのサイズを以前の上限を超えて拡張できるようにする

  • 新しい最大値を事前割り当てまたは予約しない

  • 公開iノードを追加したり変更したりしません maxfiles

  • 既存のディレクトリがすぐに容量を消費することはありません

設定されたcapとディレクトリの現在のサイズを確認する方法については、"maxdir-size と現在のディレクトリサイズの表示"を参照してください。

FlexGroupボリュームはmaxdir-sizeの制限を回避しますか?

いいえ。FlexGroupは、1つのディレクトリの `maxdir-size`を構成数で乗算することはありません。ディレクトリファイルは依然として単一の構成要素上に存在し、リモートエントリによってそのファイルはFlexVol上の同じ名前よりも速く増大する可能性があります。配置、リモートエントリの膨張、および計画数値については、"FlexGroup ボリューム"を参照してください。

"← 前へ:NetApp ONTAP NASボリュームにおける高ファイル数ワークロード"

"次へ:maxdir-size と現在のディレクトリサイズを表示する →"