Windows 2008：仮想「薄い」ディスク上の削除されたブロックの再利用
StarWind SANを使用します。これは、必要に応じて拡張するシンプロビジョニングディスクの概念を持っています。4TBドライブを割り当てることができますが、最初は小さく、ブロックが仮想ディスクに書き込まれると大きくなります（ iSCSI経由）。
メインファイルシステムに使用される仮想ディスクは1.5TBに増加し、十分な仮想スペース（2.5TB）が残っていますが、SANのディスクスペースは別の問題です。少しタイトになっています。これがシンプロビジョニングの欠点です。ディスク領域をオーバーコミットする可能性があります。
そのため、メインディスクシステムからアーカイブ領域に古いフォルダをアーカイブするのに忙しいのです。
ただし、これは、Windows 2008が削除されたブロックを再利用する場合にのみ違いがありますbefore新しいファイルが追加されると、ディスクに新しいブロックが追加されます。
これは事実ですか、それとも（物事を整頓するという利点は別として）アーカイブに時間を浪費しており、SANディスクをすぐに拡張することを検討する必要がありますか？
探しているのは、実際には「シンレクラメーション」と呼ばれます。これは、ブロックがゼロになっていない場合でも、サーバーOSがブロックのマッピングを解除したときに基盤となるストレージに通知するプロセスです。 Windows 2008は、一部のベンダーでこのように動作するように構成できますが、（少なくとも最後に私が read スターウィンドをテストしている人について）あなたのものではありません。
新しいデータをディスクに書き込む場所の決定は、Windowsでは構成できないと思います。とはいえ、簡単に構成したくないほど複雑だと確信しています。いずれの場合も、バックエンドストレージが何であるかに関係なく、Windowsが必要な場所に書き込むと想定する必要があります。
大量のファイルを削除する場合は、それらを別のシンプロビジョニングされたLUNに移行することを検討してください。これを頻繁に行う場合は、ひどい時間の無駄ですが、ストレージハードウェアを拡張したり、より永続的なソリューションを決定したりするのに十分な時間がかかります。
ベンダーに確認してください。ただし、アーカイブに時間を浪費している可能性があります。
Windowsでファイルを削除しても、LUNに割り当てられたスペースは縮小しません。 LUNに割り当てられたスペースは、LUN自体のサイズとは異なることに注意してください。 100GBのLUNをシンプロビジョニングし、それに10GBのデータを書き込むと、SANはその基盤となるディスク上の10GB相当のrawディスクブロックをLUNに割り当てます。次に、Windowsが新しいブロックに書き込みたい場合、これにより、割り当て/プロビジョニングされるシンLUN上のスペースの割合が増加します。時間の経過とともに、Windowsが元の（触れられていない）ブロックへの書き込みを要求すると、それらのブロックは未使用ブロックのグローバルプールからSANによって割り当てられ、LUNの割り当て/プロビジョニングされたサイズはさらに増加します。
最終的に、十分なデータチャーンが発生すると、シンプロビジョニングされたLUNはシックプロビジョニングされます。時間がかかる場合がありますが、OSの動作に完全に依存します。
SANはNTFS（または他のファイルシステム）自体を「見る」ことができないため、特別なソフトウェア（basilが言及している）がないと、SANはどのブロックを再利用できるかを知る方法がありません。さらに、ほとんどの場合、このソフトウェアをWindowsで実行する必要がありますbeforeボリュームはシックにプロビジョニングされますが、ベンダーに再度確認してください。
一般に、シンプロビジョニングは時間を節約しますが（最初からすべてのストレージを割り当てる必要はありません）、最終的にはボリュームをストレージで100％バックアップする必要があります。
私の理解では、Linuxは、元のブロックを使用する代わりにブロックを上書きすることを好みますが、それをバックアップするための参照がありません。