一連の同じサイズのファイルの作成/削除後のNTFSディスクのスペースの外

Question

大規模なプロジェクトに取り組んでいる間、私は本当に奇妙な問題に遭遇しました。私はたくさんのことを書きます 同じサイズ パーティション上のファイル（RAMディスクの両方を試して、VIAで作成された仮想ディスクの両方を試しました diskmgmt.msc）。別のファイルを取り付けるのに十分な空きスペースがない場合（によって報告されているように GetDiskFreeSpaceExW）、削除します （唯一） 以前に作成されたものの、新しいものを書きます。次に、別の古いファイルを削除して、新しいファイルであるAD Infinitumを書き込みます（したがって、等しくサイズのファイルのリングバッファーのようにパーティションを考えることができます）。一連の執筆者（数百から数千から数千から）の後、私は no free space 新しいファイルを書いているときにエラー（その前に、 GetDiskFreeSpaceExW 十分なスペースを報告します）。私の数人の同僚に、彼らのハードウェアの問題を再現しようとするように頼みましたが、問題は問題です しませんでした 再浮上。

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

1. ファイルサイズを選択します（たとえば、sバイト）
2. getDiskFreeSpaceExwで空きスペースを確認してください
3. free_space> s：サイズsとgoto 2の新しいファイルを書きます
4. その他：1つのファイルを削除し、GOTO 2

サイズ4096バイトのブロックでファイルにデータを記述することに注意することが重要です（ブロックサイズに応じて、問題が再浮上する場合とそうでない場合があります）。ファイルサイズは5MBです。 NTFSパーティションサイズは21 MIBです。クラスターサイズは512 Bです（再び、これらのパラメーターを変更すると結果が影響します）。これらのパラメーターを使用すると、684'thファイルの作成中に障害が発生します。 RAMディスクと仮想ディスクを使用するかどうかに依存しません（したがって、特定の実装の問題ではありません）。

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

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

• Pentium SU4100、比較的遅いデュアルコアX64 CULV CPU（1.3 GHz）
• Windows 7 Ultimate x64エディション
• 2 GB RAM

何が起こっているのか、それをどのようにデバッグするかについて誰かが考えていますか？追加情報はどこで探すことができますか？私はすでにアイデアから外れており、できるだけ早くこの問題を解決する必要があります...

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

Upd2： 質問されたいくつかの質問に答える

• パーティションは新たにフォーマットされたものです。したがって、ファイルに特定の属性も、ディレクトリ構造も、何もありません。
• 権限はデフォルトです
• no .lnk's、no hardlinks -_only_私が書いたファイル
• すべてのファイルはルート監督に書き込まれ、ディレクトリは作成されません
• ファイル名は、単にファイルの順序数です（すなわち1、2、3、...）
• 別のデータストリームはありません、 `fopen（）`を使用してファイルが作成され、 `fwrite（）`で書き込まれ、 `fclose（）`で閉じます
• $ TXFは確かに作成されます
• 悪いクラスターはありません、これは仮想（またはラム）ディスクです

Answer 1

良いNTFSの質問であり、ここでのすべての情報ではありません。ディレクターの構造とは何ですか？これにリンクファイルはありますか？ドライブで圧縮を使用していますか？ボリュームシャドウコピー？

一定のファイル /ディレクトリがあるため、MFTスペースを使い果たしません。つまり、MFTは静的です。また、低ディスクスペースシナリオでは、MFT予備スペースが拡張されます。 NTFSボリュームですべてのクラスターを使い果たしました。

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

1）$ logファイルが成長した可能性があります。これはロールバックログです。

2）ドライブに均一な権限がない場合、ファイルのセキュリティ情報の@SIIファイルが成長した可能性があります

3）そのvolme上の一部のファイルに.lnk/ショートカットファイルがそれらを指している場合、システムは各ターゲットのGUIDをインデックスに入れます。 （最近のドキュメントでは、Explorerのファイルを2倍クリックすると.lnkファイルを取得します！）

4）ディレクトリ構造は静的ではありません（またはファイル名の長さは均一ではありません）。ディレクトリの$インデックスバッファーはサイズが大きくなる可能性があります。

5）そのドライブにシステムボリュームdirectroyがある場合、ボリュームシャドウコピーとos固有のデータがある場合があります。

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

7）TXF -Vista以下では、可変空間を占めるトランザクション層がある可能性があります。

8）悪いクラスター？クラスターは悪くなる可能性があります（しかし、chkdskはこれに注意するかもしれません。）

9）ファイルが断片化され、他のメタデータを備えたフラグメントアルソンのリストがMFTレコードに収まるには大きすぎます（ファイルが小さく、ファイルが大きくないことはありません）

10）ハードリンクを使用すると、ドライブに関するデータも追加されます。

これらすべてを他の人のための参照としてリストしました！

最終メモ-NTFSレジデントファイルがMFTレコードを取り上げるだけなので、0バイトのフリーがある場合でも小さなファイルを作成して書き込むことができます（削除されたフリーレコードを変更します）

Answer 2

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

Answer 3

実装が正しく、同僚が問題を再現できないと仮定すると、それはあなたの MFT スペースが足りなくなっています。

デフォルトでは、Windows XPは、MFTを排他的に使用するために、各NTFSボリューム（MFTゾーンと呼ばれるエリア）の12.5％を予約します。したがって、ボリュームに大量の小さなファイル（8k未満、たとえば）を保存する予定がある場合、MFTはボリュームの自由スペースが行われる前にスペースがなくなる可能性があり、結果はMFTの断片化になります。

から TechNet

まず、ボリュームからファイルとディレクトリを削除しても、MFTは縮小しません。代わりに、MFTはFRSSをマークして削除を反映します。第二に、NTFSは、ファイルを参照するMFT FRSS内に非常に小さなファイルを保存します。このセットアップはこれらのファイルにパフォーマンスの利点を提供しますが、ボリュームにそのような多くのファイルが含まれている場合、MFTが過度に成長する可能性があります。

Answer 4

TXFを無効にすることがこれを修正したことはそれほど驚くことではありませんが（TXFはボリューム上のスペースを使用してファイルシステムの1つのコンポーネントにすぎません）、考慮すべき2つのことがあります。最初の、そしてもっと脇にあるのは、それを無効にすることに注意することをお勧めするかもしれないということです。 （他のコンポーネントはそれに依存する可能性があります。Windowsアップデートはそのようなコンポーネントの1つですが、システムのボリュームのみを気にするはずです。）

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

シャドウコピーに関する上記のもう1つのメモは、常に心に留めておくべきものです。

FWIW $ logファイルは自動的に成長しません。