なぜファイル数が多いと、ディスク容量が残っていてもホームNASのinodeが先に枯渇するのですか？

ファイル数が多いと、ホームNASはデータブロックを使い果たす前にinodeを使い果たすことがあります。その結果は矛盾して見えます：容量画面ではギガバイトやテラバイトの空きが表示されているのに、アップロード、バックアップ、コンテナ、インデックス作成のジョブが新しいファイルを作成できなくなります。

これはファイルシステムの制限であり、すべてのNASに共通する性質ではありません。古典的な失敗例は、定義されたinode数を持つext4や類似のファイルシステムで最もわかりやすく、XFSやBtrfsはメタデータを異なる方法で割り当てます。したがって、ファイルシステムの種類によって「空きinode」が適切な指標か、診断の一部に過ぎないかが決まります。

ホームNASはデータブロックより先にオブジェクトスロットを使い果たすことがある

直接の原因は、ファイルデータとファイル識別子が異なるリソースを消費することです。ext4では、inodeはタイムスタンプ、所有権、ブロックマッピング、拡張属性などのメタデータを記録し、ディレクトリエントリは名前とinodeを関連付けます。Linuxカーネルのext4 inodeドキュメントは、inodeテーブルをブロックグループに分散された線形配列として説明しています。

新しい通常ファイルは通常inodeを必要としますが、バイトサイズが必要なinode数を決定するわけではありません。100GBのビデオは1つのinodeを占有することができますが、100万個の小さなキャッシュファイルは約100万個のinodeを必要とします。ディレクトリやシンボリックリンクもファイルシステムオブジェクトであり、同じファイルへの複数のハードリンクは1つのinodeを共有します。

したがって、最後の空きinodeが割り当てられた後でも空きブロックは利用可能なままであることがあります。その時点で、NASは理論上さらにファイルコンテンツのための空き容量がありますが、別のオブジェクトを作成するために必要なメタデータの識別子が不足しています。容量とオブジェクト数は独立しているため、両方を監視する必要があります。

なぜ小さなファイルは容量よりも速くinodeを消費するのか

小さなファイルは高いオブジェクト密度を生み出します：比較的少ないペイロードに対して多くの識別子が必要です。ゼロバイトのファイルでもメタデータが必要であり、ディレクトリツリーは中のファイルがカウントされる前に独自のディレクトリinodeを追加します。これが、ワークロードがNASの公称テラバイト容量よりもはるかに速くファイルスロットを消費する理由です。

ext4では、作成ツールがバイトあたりinode比率からinode数を計算するか、明示的なinode数を受け入れます。mke2fsのinode割り当てオプションによると、バイトあたりinode比率が大きいほどinode数は少なくなり、ファイルシステム作成後に比率を変更できませんが、リサイズ時には新しい領域にinodeを追加して設定された比率を維持します。

単純な計画モデルはおおよそのinode数 = ファイルシステムサイズ ÷ バイトあたりinode比率です。仮に16KiBの比率を使うと、1TiBはフォーマットのオーバーヘッドやファイルシステムの制限を考慮する前で約6700万のinodeスロットに相当します。これは例示であり、すべてのNASのデフォルトではありません。フォーマットプロファイルやファイルシステムの実装によって異なる方針が選ばれます。

最後の空きinodeが割り当てられたときに何が変わるか

典型的な枯渇ケースでは、新しいinodeが必要な操作が失敗し始めます。新規アップロード、ディレクトリ、一時ファイル、展開されたアーカイブメンバー、アプリケーションの状態ファイルなどがすべて拒否される可能性がありますが、既存のファイルはまだ読み取り可能です。既存ファイルは、すでにinodeを所有していて空きデータブロックが残っていれば、サイズを拡張できる場合もあります。

アプリケーションはしばしば割り当て失敗を「デバイスに空き領域がありません」という一般的なメッセージに変換します。このメッセージはリソース割り当ての失敗を示しますが、欠落しているリソースがデータブロック、inode、クォータ許容量、またはファイルシステム固有のメタデータ領域のどれかはユーザーに伝えません。表示されるエラーはファイルシステムのカウンターと組み合わせて確認する必要があります。

どのホームNASワークロードが極端なファイル数を生み出すか

リスクのあるワークロードは単なる「大容量データ」ではありません。多くの独立したファイルシステムオブジェクトを生成し、特にクリーンアップや保持によってそれらのオブジェクトが数ヶ月間蓄積されるワークロードです。

コンテナレイヤー、ログ、パッケージツリー

コンテナイメージ、抽出されたソフトウェアパッケージ、依存関係ツリー、ローテーションログ、アプリケーションキャッシュは、多数の小さなオブジェクトを1つのNASホストサービスの下に配置することがあります。コンテナイメージはギガバイト単位で控えめに見えても、展開されたレイヤーや書き込み可能な状態は同じサイズのメディアファイルよりはるかに多くのオブジェクトIDを消費します。

写真のサムネイルと検索インデックス

写真管理ソフトは、各ソース資産に対してサムネイル、プレビュー、サイドカー、顔切り抜き、またはインデックス断片を生成できます。アプリケーションによってはこれらの記録をデータベースに統合するものもあれば、多くを通常のファイルとして保存するものもあり、inodeの影響は写真ライブラリのサイズだけでなくアプリケーションのストレージ設計に依存します。

同期履歴、バックアップツリー、メールストア

ファイルとしてリビジョンを具現化するバージョニングシステム、多数のソースオブジェクトを含むバックアップツリー、および1ファイル1メッセージのメールストアはすべて高いファイル数を生み出す可能性があります。コピーオンライトスナップショットや重複排除されたリポジトリはバージョンを異なる方法で表現するため、スナップショット数を実装を確認せずに直接inode数として扱うべきではありません。

なぜ容量ダッシュボードはinode圧力を見逃すのか

多くのダッシュボードはバイト数（総容量、使用済みブロック、空きブロック）を強調します。標準のファイルシステム統計インターフェースはオブジェクトカウンターを合計、空き、利用可能なファイルシリアル番号として別々に保持し、Linuxではstatvfsファイルシステム統計のf_filesやf_ffreeなどのフィールドに対応します。これらのフィールドを省略するUIは、典型的なinode枯渇時に正常に見えることがあります。

シェルアクセス可能なLinuxベースのNASでは、同じマウントパスのブロック使用量とinode使用量を比較できます：

df -h /path/on/nas
df -i /path/on/nas

GNU dfマニュアルは-iをブロック使用量ではなくinode使用量として定義し、合計、使用済み、利用可能、および割合のフィールドを表示します。空きinodeがゼロで空きブロックがある場合は典型的なinode枯渇を強く示し、両方に余裕がある場合は別の制限を示唆します。

固定inodeファイルシステムと動的inodeファイルシステムは異なる方法で失敗します

「NASがinodeを使い果たした」は、ファイルシステムの割り当てモデルと報告されたカウンターがそれを支持する場合にのみ正確です。同じ空き容量なしのメッセージが、別のファイルシステムの異なるメタデータ境界から来ることもあります。

XFSのinodeスペースポリシーはinodeに割り当てられるファイルシステムの割合を制限することがあり、公式のBtrfsファイルシステムの報告はデータ、システム、メタデータ、グローバルリザーブを区別します。これらのモデルはメタデータ関連の制限を生じさせることがありますが、すべてのNASが同じ固定inodeテーブルを持つかのように説明すべきではありません。

一般的な統計インターフェースは、返されるすべてのフィールドがすべてのファイルシステムで意味を持つわけではないことも警告しています。まずマウントされたファイルシステムを特定し、それから解釈してください。 df -i 1つのコマンドを普遍的な証拠として扱うのではなく、その実装を通じて理解してください。

NAS容量計画におけるinodeの余裕の意味

高オブジェクト数のワークロードの容量予測には、予想されるバイト数と予想されるオブジェクト数の両方が必要です。メディアアーカイブは通常バイト密度が高い一方、依存関係ツリー、サムネイル、メールストア、マテリアライズドバックアップツリーはオブジェクト密度が高いです。同じ論理サイズの2つのワークロードでも、必要なメタデータの余裕は大きく異なる場合があります。

ext4ボリュームの場合、バイトあたりのinode比率はフォーマット時の設計上の選択であり、通常のライブチューニングの調整項目ではありません。リサイズは既存の比率に沿ってinodeを追加できますが、過去に遡って密度の高いプロファイルを選ぶことはできません。その比率を変更するためだけの再フォーマットは、バックアップと復元の影響を伴う移行の決定であり、気軽なパフォーマンス調整ではありません。

inodeの圧迫が原因でないことが判明したら、通常のブロック容量の問題は別に考えます。ホームNASのストレージ容量計画がその判断を補助しますが、空きテラバイト数の指針はinodeやメタデータの数に代わるものではありません。

なぜ大きなファイルを1つ削除しても十分なinodeが回復しないのか

大きな映画ファイルを1つ削除すると多くのデータブロックが解放されますが、通常は1つのinodeしか解放されません。数十万の不要なキャッシュオブジェクトを含むディレクトリツリーを削除すると、回収されるバイト容量が比較的小さくても多くのinodeが解放されることがあります。クリーンアップは枯渇しているリソースに合わせる必要があります。

リンクが外されたオブジェクトは必ずしもすぐに回収されるわけではありません。Linuxのunlink動作では、プロセスが最後のリンクをまだ開いている場合、ファイルは存在し続け、最後の参照ファイルディスクリプターが閉じられた後に解放されます。そのため、inodeの回収はアクティブなログやサービスファイルのパス名削除より遅れることがあります。

よくある質問

すべてのファイルは正確に1つのinodeを使いますか？

通常、通常のファイルは1つのinodeを持ち、ディレクトリやシンボリックリンクもそれぞれ独自のファイルシステムIDを持ちます。複数のハードリンク名が同じinodeを指すことがあり、ファイルシステム固有の機能は追加のメタデータを別のオブジェクトに格納することもあるため、パス名の数とinode数は関連していますが必ずしも同一ではありません。

SSDキャッシュや高速ネットワークはinode枯渇を防げますか？

いいえ。高速なメディアやネットワークはレイテンシを減らしたりスループットを増やしたりできますが、固定されたinode数の中で追加のinodeスロットを作成することはできません。高ファイル数のワークロードをより速く完了させ、同じメタデータ制限に早く到達させることはあります。

はどうですか？ df -i すべてのホームNASファイルシステムで機能しますか？

マウントされたファイルシステムインターフェースを通じて提供されるinodeスタイルのカウンターを報告しますが、これらのカウンターはすべてのファイルシステムで同じ意味を持つとは限りません。ext4スタイルの診断には直接使用し、XFS、Btrfs、ZFS、または基盤となるボリュームを抽象化するアプライアンスにはファイルシステム固有のメタデータツールと組み合わせて使用してください。

ext4ファイルシステムの拡張でinodeを増やせますか？

はい。ext4のリサイズは、新しいスペースを取り込む際にinodeを追加し、既存のバイト数あたりinode比率を維持できます。これは既存のファイルシステム上で比率を変更することとは異なり、作成ツールのドキュメントではフォーマット後の比率変更はサポートされていません。

「デバイスに空き領域がありません」というエラーはすべてinodeが原因ですか？

いいえ。満杯のデータブロック、クォータ、予約済みスペース、Btrfsのメタデータ割り当て、一時スペース制限、および一部の非ストレージリソース制限が同様のメッセージを引き起こすことがあります。inode枯渇は、ファイルシステムオブジェクトの作成に失敗し、関連するinodeカウンターに利用可能なエントリがない場合にサポートされます。

ファイル数は独自の容量次元です

ホームNASは空きディスク容量を保持しつつ、新しいオブジェクトの受け入れを停止することがあります。これはバイト数とファイルシステムのメタデータが別々の容量次元であるためです。ファイル数の多さをワークロードの特性として扱い、実際のファイルシステムを確認し、ディスクが満杯と結論付ける前にブロックの余裕とinodeやメタデータの余裕を比較してください。