NASは空き容量を報告しているのに、なぜ新しい大容量ファイルを拒否するのか？
NASは空き容量があるように表示されていても、保存先のクォータ、メタデータ、ファイル数の上限、または書き込み可能な割り当て容量を使い果たしていると、大きなファイルを拒否することがあります。
ダッシュボードにはプール全体の空き容量が表示される一方、共有フォルダーは、より小さなデータセット、シンボリューム、ユーザークォータ、予約済みファイルシステム、またはメタデータ領域がほぼ枯渇したプロファイルに属している場合があります。また、大きなアップロードでは、一時領域や2つ目のコピーが必要になったり、保存先のファイルシステムで扱えない単一ファイルサイズになったりすることもあります。まず、表示上の空き容量が操作に適用されると決めつけず、実際に失敗したパスとエラーコードを確認してください。
共有フォルダーが実際に使用しているファイルシステムと制限を特定する
SMB共有またはアプリケーション共有をホスト上のパス、マウントポイント、データセット、サブボリューム、シンボリューム、基盤となるプールまでたどります。空きブロック、空きinode、ユーザーID、拒否されたファイルのサイズを記録してください。
GNUの説明によると、dfはパスに対応するマウント済みファイルシステムを報告するものであり、その上下にあるすべてのプール、クォータ、スナップショット、アプリケーションレベルの制限を報告するものではありません。
共有フォルダーがシステムパーティションや、より小さなマウント済みデータセットに書き込んでいる場合、プール全体の空き容量は関係ありません。誤ったストレージ層のデータを削除する前に、パスまたはマウントを修正してください。
ユーザー、グループ、データセット、共有フォルダーのクォータを確認する
管理者向けの空き容量表示と、実際のSMBユーザー、グループ、データセット、プロジェクト、共有フォルダーに適用されているクォータを比較します。エラーを受け取るアカウントと同じアカウントでテストしてください。
Oracleの説明では、ZFSのクォータと予約により、未使用のプール容量が残っていても1つのデータセットを制限したり、別のデータセット用に空き容量を予約したりできます。
クォータを一括で削除しないでください。実際に原因と確認できた制限だけを引き上げるか、ワークロードに合った容量ポリシーを持つデータセットへファイルを移動してください。
データ領域とメタデータおよび割り当て用ワークスペースを比較する
データ、メタデータ、システム割り当て、ブロックグループ、ファイルシステム固有の予約カウンターを確認します。大きなファイルの作成では、データ本体の容量に加えて、メタデータの更新やコピーオンライト用のワークスペースが必要になる場合があります。
Btrfsのドキュメントでは、割り当てとコピーオンライトに必要な領域を確保できない場合、空き容量が表示されていてもENOSPCになることがあると説明されています。
メタデータが制限されている場合は、サポートされているファイルシステム診断と、影響範囲を絞った復旧操作を使用してください。残りの領域を別の大きなテストファイルで埋めたり、ワークスペースを測定せずにフィルターなしのバランス処理を開始したりしないでください。
inodeとファイルレコードの制限を確認する
空きinodeまたはファイルレコードを記録し、キャッシュ、メールストア、サムネイル、展開済みパッケージ、アプリケーションディレクトリ内の小さなファイル数を確認します。バイト単位の容量が十分でも、別のディレクトリエントリやメタデータレコードを割り当てられるとは限りません。
Red Hatのファイルシステム概要では、XFSがinodeを動的に割り当てること、およびファイルシステムの実装ごとに異なるinodeとファイルレコードの制限があることを説明しています。
inodeを使い果たしている場合は、所有するアプリケーションを通じて、ファイル数が多いことを確認済みのキャッシュを削除またはアーカイブしてください。大きなファイルを1つ削除しても、ファイルレコード不足は解決しません。
保存先の最大ファイルサイズと形式を確認する
保存先のファイルシステムを特定し、試行したアップロードのサイズと、単一ファイルの最大サイズを比較します。リムーバブルな作業用ディスク、USBバックアップ先、アプリケーションの一時フォルダーも含めて確認してください。
MicrosoftのNTFS概要では、最大ファイルサイズはファイルシステムの設計と割り当てパラメーターに依存するため、全体の空き容量が単一ファイル形式の制限を上書きすることはないと説明しています。
4GBなど一貫した境界付近で失敗する場合は、途中にあるすべてのファイルシステムとアップロード経路を確認してください。再フォーマットするとデータが消去されるため、保存先の形式を変更する前に、確認済みのファイルを別の場所へ移行してください。
一時領域、スパースファイル、事前割り当ての要件を測定する
アップローダーが一時ファイルを書き込むか、保存先全体を事前に割り当てるか、名前変更まで旧バージョンを保持するか、またはアーカイブを追加ファイルとして展開するかを確認します。最終的なファイルサイズではなく、ピーク時の割り当て容量を記録してください。
fallocateシステムコールはディスク領域を事前に予約するため、後続の書き込みが容量不足で失敗しないようにします。そのため、アプリケーションはデータをすべて転送する前に大きなファイルを拒否することがあります。
一時ディレクトリを目的のデータプール上に設定するか、アプリケーションが安全に対応している場合に限り事前割り当てを無効にします。置き換え中は、元のファイル、一時コピー、メタデータ、スナップショットに必要な十分な余裕を確保してください。
制御されたファイルで正確なエラーを再現する
同じユーザー、プロトコル、パス、アプリケーションを使用して、失敗したサイズより小さいテストファイルと大きいテストファイルを作成します。本番ファイルを何度も再試行せず、クライアントのエラーとサーバーログを取得してください。
ZimaSpaceの予想外のNAS容量使用量を特定する方法では、表示上のフォルダーと実際のファイルシステム割り当てを突き合わせるための、関連する確認方法を紹介しています。
原因と確認できたクォータ、メタデータ、inode、形式、または一時領域の制限を修正し、以前に失敗したサイズを超えるファイルが正常に書き込まれ、クローズ、再オープン、検証まで完了すれば、問題は解決です。ファイルシステムが読み取り専用になった場合や、破損またはハードウェアエラーが報告された場合は、書き込みを停止してください。
おすすめ商品
サポートとヒント
もっと読む
Plexは別のDockerコンテナとGPUを共有できますか？
Plexと別のコンテナは同じGPUにアクセスできることが多いですが、ドライバーのサポート、デバイスマッピング、ビデオエンジンの負荷、メモリ、復旧動作をテストする必要があります。
Plexのエラーがクライアント側とサーバー側のどちらに起因するかを見分ける方法
別のクライアントで同じ項目を再現し、セッションパスを比較してから、スコープによって障害の実際の所在が特定された後にのみサーバーの証拠を収集してください。
Plexのキャッシュとトランスコード用一時ストレージを設定する方法
永続的な Plex の状態を保護しつつ、トランスコードの一時ファイルを適切なローカルストレージに配置し、クリーンアップ、空き容量、再起動時の動作を確認します。
