2

大規模なプロジェクトに取り組んでいるときに、非常に奇妙な問題に遭遇しました。同じサイズのファイルをパーティションに書き込みます (RAM ディスクと で作成した仮想ディスクの両方を試しましたdiskmgmt.msc)。別のファイルを収めるのに十分な空き容量がない場合 ( で報告されているように)、以前に作成したファイルの 1 つ(1 つだけ)GetDiskFreeSpaceExWを削除し、新しいファイルを書き込みます。次に、別の古いファイルを削除し、無限に新しいファイルを書き込みます (したがって、パーティションは同じサイズのファイルのリング バッファーと考えることができます)。一連の書き込みと削除 (数百から数千) の後、新しいファイルの書き込み中にエラーが発生しました (その前に、十分なスペースが報告されます)。私は何人かの同僚に、彼らのハードウェアで問題を再現するように依頼しましたが、問題はno free spaceGetDiskFreeSpaceExW再浮上しませんでした。

物事を少し明確にするために、正確なアルゴリズムは次のとおりです。

  1. ファイルサイズを選択してください (たとえば、S バイト)
  2. GetDiskFreeSpaceExW で空き容量を確認する
  3. free_space > S の場合: サイズ S の新しいファイルを書き込み、2 に進む
  4. Else: 1 つのファイルを削除して 2 に進む

サイズが 4096 バイトのブロックでファイルにデータを書き込むことに注意することが重要です (ブロック サイズによっては、問題が再発生する場合と発生しない場合があります)。ファイルサイズは5MBです。NTFS パーティション サイズは 21 MiB です。クラスタ サイズは 512 B です (ここでも、これらのパラメータを変更すると結果に影響します)。これらのパラメータでは、684 番目のファイルの作成中にエラーが発生します。RAM ディスクと仮想ディスクのどちらを使用するかには依存しません (したがって、特定の実装の問題ではありません)。

障害発生後に得られたディスク イメージ ダンプを分析したところ、ファイルが大幅に断片化されていることがわかりました。Chkdsk では、実験の前後に問題は報告されていません。システム ログにエラーは見つかりませんでした。

私のネットブック（Dell Inspiron 1110）のおそらく関連するパラメータ：

  • Pentium SU4100、比較的遅いデュアルコア x64 CULV CPU (1.3 GHz)
  • Windows 7 アルティメット x64 エディション
  • 2GBのRAM

何が起こっているのか、それをデバッグする方法について何か知っている人はいますか? 追加情報はどこで確認できますか? 私はすでにアイデアが尽きており、できるだけ早くこの問題を解決する必要があります...

UPD:ファイルを作成するときではなく、ファイル データを書き込んでいるときに問題が発生します (つまりwrite()、失敗します) 。したがって、MFT エントリが不足しているようには見えません。

UPD2:寄せられたいくつかの質問に答える

  • パーティションは新しくフォーマットされたものであるため、ファイルの特定の属性、ディレクトリ構造、何もありません
  • 権限はデフォルトです
  • .lnk もハードリンクもありません - 私が書いたファイルのみ
  • すべてのファイルはルート ディレクトリに書き込まれ、それ以上のディレクトリは作成されません
  • ファイル名は単純にファイルの序数です (つまり、1、2、3、...)
  • 代替データ ストリームはありません。ファイルは `fopen()` を使用して作成され、`fwrite()` で書き込まれ、`fclose()` で閉じられます。
  • 確かに $Txf が作成されます
  • 不良クラスタはありません。これは仮想 (または RAM) ディスクです
4

4 に答える 4

1

FSには、考慮しない独自のオーバーヘッドがあります。そのオーバーヘッドは一定ではないため、ファイルを削除/書き込みすると、断片化が発生する可能性があります。つまり、「5 MBの空き容量」は、ディスクに5MBを書き込むことができることを意味するものではありません。

于 2010-08-25T12:34:52.850 に答える
1

実装が正しく、同僚が問題を再現できないと仮定すると、MFTのスペースが不足している可能性があります。

デフォルトでは、Windows XPは各NTFSボリューム（MFTゾーンと呼ばれる領域）の12.5パーセントをMFT専用に予約します。したがって、ボリュームに大量の小さなファイル（たとえば、8K未満）を保存する場合、ボリュームの空き領域よりも先にMFTの領域が不足する可能性があり、その結果、MFTが断片化されます。

Technetから

まず、ボリュームからファイルとディレクトリを削除しても、MFTは縮小しません。代わりに、MFTは削除を反映するようにFRSにマークを付けます。次に、NTFSは、ファイルを参照するMFTFRS内に非常に小さなファイルを格納します。この設定はこれらのファイルのパフォーマンス上の利点を提供しますが、ボリュームにそのようなファイルが多数含まれている場合、MFTが過度に大きくなる可能性があります。

于 2010-08-25T12:35:08.310 に答える
1

ここにすべての情報が含まれているわけではありません。ディレクトリ構造とは何ですか。これにLINKファイルはありますか？ドライブで圧縮を使用していますか? ボリューム シャドウ コピー？

ファイル/ディレクトリの数は一定であるため、MFT スペースが不足することはありません。つまり、MFT は静的です。また、MFT 予約領域は、ディスク領域が少ないシナリオで使用されます。NTFS ボリューム上のすべてのクラスターを使い果たしました。

何が起こっているかについては、いくつかの説明があります。

1) $Log ファイルが大きくなっている可能性があります。これはロールバック ログです。

2) ドライブに不均一な権限がある場合、ファイルのセキュリティ情報の @SII ファイルが大きくなる可能性があります。

3) そのボリューム上の一部のファイルに、それらを指す .lnk/ ショートカット ファイルがある場合、システムは各ターゲットの GUID をインデックスに入れます。(最近のドキュメントでは、エクスプローラーでファイルを 2 回クリックすると、.lnk ファイルが表示されます!)

4) ディレクトリ構造が静的ではない (またはファイル名の長さが均一でない) ディレクトリの $index バッファのサイズが大きくなる可能性があります。

5) そのドライブにシステム ボリューム ディレクトリがある場合は、ボリューム シャドウ コピーやその他の OS 固有のデータがある可能性があります。

6) 代替データ ストリームは、ファイルのサイズに表示されません。いずれかがあります？

7) TxF - Vista 以降では、変数領域を占有するトランザクション層が存在する場合があります。

8) 不良クラスタ? クラスターが不良になる可能性があります (ただし、chkdsk はこれに注意する場合があります..)

9) ファイルが断片化され、他のメタ データを含む断片のリストが大きすぎて MFT レコードに収まりません (ファイルが小さく、非常に長いファイルがない場合はほとんどありません)。

10) ハードリンクを使用すると、より多くのデータがドライブに置かれます。

他の方の参考になればと思いリストアップしました！

最後の注意 - NTFS 常駐ファイルは MFT レコードのみを使用するため (削除された空きレコードを再開するため)、空き容量が 0 バイトであっても小さなファイルを作成して書き込むことができる場合があります。

于 2010-08-25T17:53:13.337 に答える
0

TXF を無効にすれば問題が解決することは驚くべきことではありませんが (TXF は、ボリューム上のスペースを使用するファイル システムのコンポーネントの 1 つにすぎません)、考慮すべき点が 2 つあります。最初の、そしてもっと余談ですが、実際には、それを無効にすることに注意する必要があるかもしれません. (他のコンポーネントはそれに依存している可能性があります。Windows Update はそのようなコンポーネントの 1 つですが、システム ボリュームのみを考慮する必要があります。)

考慮すべきもう 1 つのことは、これは一般的かつ実質的に脆弱なパターンであるということです。ファイル システムには、何を消費できるかについていくつかの前提があります。たとえば、インデックスは (定義済みの増分で、変更される可能性があります) 成長し、予測可能な方法で縮小しない場合があります。さらに、セキュリティ記述子のインデックスは、今後も増加し続ける可能性があります。

上記のシャドウ コピーに関するその他の注意事項は、常に念頭に置いておく必要があります。

FWIW $Log ファイルは自動的に大きくなりません。

于 2010-08-27T13:51:14.333 に答える