次の方法で共有

Azure NetApp Files のディレクトリ サイズを理解する

  • [アーティクル]

ディレクトリにファイルが作成されると、Azure NetApp Files ボリューム内の非表示のインデックス ファイルにエントリが追加されます。 このインデックス ファイルは、ディレクトリ内の既存の inode を追跡するのに役立ち、ファイル数が多いディレクトリに対する検索要求を高速化するのに役立ちます。 このファイルにエントリが追加されると、ファイル サイズはファイル名の長さに応じて、エントリあたり約 512 バイトの割合で増加します (ただし、減少することはありません)。 ファイル名が長いほど、ファイルのサイズが増えます。 シンボリック リンクの場合も、このファイルにエントリが追加されます。 この概念はディレクトリ サイズとして知られています。これは、Linux ベースのすべてのファイルシステムにおける共通の要素です。 ディレクトリ サイズは、1 つの Azure NetApp Files ボリューム内のファイルの最大数ではありません。 それは、maxfiles 値によって決まります。

既定では、新しいディレクトリが作成されると、4 KiB (4,096 バイト) または 8 個の 512 バイト ブロックが消費されます。 stat コマンドを使用して、Linux クライアントから新しく作成されたディレクトリのサイズを表示できます。

# mkdir dirsize 
# stat dirsize 
File: ‘dirsize’ 
Size: 4096            Blocks: 8          IO Block: 32768  directory

ディレクトリ サイズは 1 つのディレクトリに固有であり、サイズが結合されることはありません。 たとえば、ボリュームに 10 個のディレクトリがある場合、それぞれが 1 つのボリュームで 320 MiB のディレクトリ サイズ制限に近づく可能性があります。

ディレクトリのサイズが上限に近づいているかどうかの確認

320 MiB のディレクトリの場合、ブロック数は 655,360、各ブロック サイズは 512 バイトです (つまり、320 x 1024 x 1024/512)。320 MiB のディレクトリの場合、この数値は最大約 400 万から 500 万ファイルに換算できます。 ただし、ASCII 以外の文字を含むファイルがディレクトリ内にどの程度存在するかといった要因によっては、実際の最大ファイル数が少なくなる場合があります。 クライアントから stat コマンドを使用することで、ディレクトリがディレクトリ メタデータのサイズ上限 (320 MB) に近づいているかどうかを確認できます。 Azure NetApp Files の単一ディレクトリの最大サイズ制限に達すると、エラー No space left on device が発生します。

320 MB のディレクトリの場合、ブロック数は 655,360、各ブロック サイズは 512 バイトです。 (つまり、320 x 1,024 x 1,024/512)。320 MB のディレクトリの場合、この数値は最大約 400 万ファイルに換算できます。 ただし、ASCII 以外の文字を含むファイルがディレクトリ内にどの程度存在するかといった要因によっては、実際の最大ファイル数が少なくなる場合があります。 maxdirsize を監視する方法については、「maxdirsize を監視する」を参照してください。

ディレクトリ サイズに関する考慮事項

ファイル数の多い環境を扱う場合は、次の推奨事項を考慮してください。

  • Azure NetApp Files ボリュームでは、ディレクトリ サイズとして最大 320 MiB がサポートされます。 この値を増やすことはできません。
  • ボリュームのディレクトリ サイズを超えると、ボリュームに空き領域がある場合でも、クライアントに領域不足エラーが表示されます。
  • 通常のボリュームの場合、320 MiB というディレクトリ サイズは、1 つのディレクトリ内の約 400 万から 500 万個のファイルに相当します。 この値は、ファイル名の長さに依存します。
  • 大容量ボリュームのアーキテクチャは、通常のボリュームとは異なります。
  • 1 つのディレクトリのファイル数が多い場合、検索時にパフォーマンスの問題が発生する可能性があります。 頻繁な検索が必要な場合は、可能であれば 1 つのディレクトリの合計サイズを 2 MiB (約 27,000 ファイル) に制限します。
    • 1 つのディレクトリにさらにファイルが必要な場合は、それに応じて検索のパフォーマンスの期待値を調整します。 Azure NetApp Files では、パフォーマンスのためにディレクトリ ファイルの一覧にインデックスが付けられますが、ファイル数が多い場合は検索に時間がかかることがあります。
  • ファイル システムを設計するときは、フラットなディレクトリ レイアウトを避けてください。 ディレクトリ レイアウトについてのさまざまなアプローチについては、「ディレクトリ レイアウトについて」を参照してください。
  • ディレクトリ サイズを超えたために新しいファイルを作成できないという問題を解決するには、関係するディレクトリからファイルを削除または移動します。

ディレクトリ レイアウトについて

フラット ディレクトリ構造を使用している場合、つまり 1 つのフォルダー内に単一レベルで何百万ものファイルが含まれている場合は、maxdirsize 値が問題となる可能性があります。 ファイル、フォルダー、サブフォルダーが混在するフォルダー構造の場合は、maxdirsize への影響が少なくなります。 ディレクトリ構造にはいくつかの手法があります。

フラット ディレクトリ構造は、同じディレクトリの下に多数のファイルがある単一のディレクトリです。

フラット ディレクトリ構造の図。

ワイド ディレクトリ構造には多数の最上位レベル ディレクトリが含まれており、すべてのディレクトリにファイルが分散しています。

ワイド ディレクトリ構造の図。

ディープ ディレクトリ構造には、少数の最上位レベル ディレクトリと多数のサブディレクトリが含まれています。 この構造ではフォルダーあたりのファイル数は少なくなりますが、ディレクトリ レイアウトが深すぎてファイル パスが長くなりすぎると、ファイル パスの長さが問題になる可能性があります。 ファイル パスの長さの詳細については、「Azure NetApp Files でのファイル パスの長さを理解する」を参照してください。

ディープ ディレクトリ構造の図。

Azure NetApp Files でのフラット ディレクトリ構造の影響

フラット ディレクトリ構造 (1 つまたは少数のディレクトリ内に多数のファイル) は、さまざまなファイル システム、Azure NetApp File ボリュームなどに悪影響を及ぼします。 次のような問題の可能性があります。

  • メモリ不足
  • CPU 使用率
  • ネットワーク パフォーマンス/待機時間 (特に、ファイルの大量クエリ、GETATTR 操作、READDIR 操作の際)

Azure NetApp Files 大容量ボリュームの設計により、maxdirsize の影響は固有です。 Azure NetApp Files 大容量 maxdirsize は、その設計により影響は固有です。 大容量ボリュームは通常のボリュームとは異なり、Azure NetApp Files 内のリモート ハード リンクを使用してさまざまなストレージ デバイス間でトラフィックをリダイレクトし、より高いスケールとパフォーマンスを実現するのに役立ちます。 フラット ディレクトリを使用する場合、ローカル ファイルに対する内部リモート ハード リンクの比率が高くなります。 これらのリモート ハード リンクは合計 maxdirsize 値に対してカウントされるため、大容量ボリュームが通常のボリュームよりも早く maxdirsize 制限に近づく可能性があります。

たとえば、1 つのディレクトリに数百万ものファイルがあり、ファイル システムの約 85% のリモート ハード リンクが生成される場合、通常のボリュームの約 2 倍の量で maxdirsize が使い果たされる可能性があります。

Azure NetApp Files のディレクトリ サイズで最良の結果を得るには:

  • Azure NetApp Files でフラット ディレクトリ構造を使用しないでください。 ファイルまたはフォルダーのファイル パスの長さが NAS プロトコル標準を超えていない場合、ワイドまたはディープ ディレクトリ構造が最適に機能します。
  • フラット ディレクトリ構造が避けられない場合は、ディレクトリの maxdirsize を監視します。

maxdirsize を監視する

単一ディレクトリの場合は、stat コマンドを使用してディレクトリ サイズを確認します。

# stat /mnt/dir_11/c5

stat コマンドを使用して特定のディレクトリのディレクトリ サイズを確認できますが、1 つのディレクトリに対して個別に実行することが効率的でない場合があります。 最大から最小の順に並べ替えられた最大ディレクトリ サイズの一覧を表示するには、次のコマンドを実行すると、クエリからスナップショット ディレクトリを省略して、それを行うことができます。

# find /mnt -name .snapshot -prune -o -type d -ls -links 2 -prune | sort -rn -k 7 | head | awk '{print $2 " " $11}' | sort -rn

Note

stat コマンドによって報告されるディレクトリ サイズはバイト単位です。 find コマンドで報告されるサイズは KiB 単位です。

例

# stat /mnt/dir_11/c5 

  File: ‘/mnt/dir_11/c5’ 

  Size: 322396160       Blocks: 632168     IO Block: 32768  directory 
 
# find /mnt -name .snapshot -prune -o -type d -ls -links 2 -prune | sort -rn -k 7 | head | awk '{print $2 " " $11}' | sort -rn 
316084 /mnt/dir_11/c5 

3792 /mnt/dir_19 

3792 /mnt/dir_16

先ほどの場合、/mnt/dir_11/c5 のディレクトリ サイズは 316,084 KiB (308.6 MiB) であり、320 MiB の制限に近づいています。 これは約 410 万個のファイルに相当します。

# ls /mnt/dir_11/c5 | wc -l
4171624

この場合は、ファイルの移動や削除などの是正措置を検討してください。

詳細