Windows ServerでReFSを使っていると、Sysinternals SDelete 2.02 を実行しても「Purging MFT」から完了しないことがあります。この記事では、公式情報から分かるReFS互換性の扱いと、目的別に失敗しにくい代替策・運用手順を整理します。
起きている症状と、混乱しやすいポイント
今回の論点はシンプルで、次の2つが同時に起きることで判断が難しくなっています。
- ReFSボリュームに対して SDelete 2.02 を実行できてしまう（＝動くように見える）
- ところが最終盤のように見える「Purging MFT」フェーズで終わらない、もしくは進捗表示が異常になる
そして重要なのが、「動く」ことと「対応している（保証されている）」ことは別という点です。特にストレージ系のツールは、ファイルシステム仕様・OSバージョン・仮想化・アレイの実装差で挙動が変わりやすく、“たまたま動いている”状態が発生しがちです。
実際、Microsoft Q&A にある当該スレッド（SDelete 2.02 / ReFS / Purging MFTで終わらない）でも、受理回答は「ReFS互換です」と断言せず、専用窓口へ問い合わせる流れになっています。
SysInternals SDelete 2.02 – Is it compatible with ReFS ?（Microsoft Q&A）
結論としての整理
結論から言うと、SDeleteは公式ドキュメント上、ReFS対応を明言していません。そのため、ReFS上で動作したとしても、運用設計としては次の扱いが安全です。
- 「ReFSでの互換性は未確認（少なくとも明文化された保証はない）」として扱う
- 公式の回答が必要なら、Sysinternalsの窓口（Microsoft Q&A）に事例を添えて質問する
Sysinternalsの質問窓口は現在、Microsoft Q&A（Sysinternalsタグ）に集約されています。
Sysinternals Community（Microsoft Learn）
Sysinternals – Microsoft Q&A（タグ一覧）
また、SysinternalsツールはライセンスFAQ上も「as is」で、公式のMicrosoftサポートが付く性質のものではありません。困ったときの一次窓口はコミュニティになります。
Sysinternals Licensing FAQ（Is there technical support available?）
「Purging MFT」とは何をしているのか
「Purging MFT」が何かを理解すると、ReFSで違和感が出る理由が見えてきます。
SDelete公式ページ（現行ドキュメントは v2.05）では、空き領域の消去（clean/zero）を次の考え方で実現すると説明しています。
- 空き領域に直接書き込むのではなく、巨大なファイルを作ってディスクを埋めることで、結果的に空き領域を上書きする
- NTFSの場合はさらに、NTFSのMFT（Master File Table）の未使用領域も埋める必要がある
実際にドキュメントには、NTFSのMFT未使用領域を埋める工程が明記されています（MFTレコードは通常1KB、などの記述もあります）。
SDelete – Sysinternals（How SDelete Works / NTFS MFTの説明）
つまり、SDeleteの「Purging MFT」は、NTFSのMFTという前提に強く依存した工程です。ReFSはNTFSとは異なるメタデータ構造を持つため、SDeleteの説明通りに“意味のある”処理になっているかは、少なくともドキュメントだけでは判断できません。
フェーズ別に見ると何が起きているか
| 表示されるフェーズ | 公式説明上の目的 | 代表的な挙動 | ReFSでの注意点 |
|---|---|---|---|
| Cleaning free space | 未割り当て領域の上書き（安全消去/ゼロ化） | 巨大な一時ファイルを作り、ボリュームが一時的に満杯になることがある | この工程自体は「大きいファイルを書いて消す」発想なので、ReFSでも動いて見えやすい |
| Purging MFT | NTFSのMFT未使用領域を、MFT内に収まる小さなファイルで埋める | 小さな書き込みが大量に発生し、遅くなりやすい／進捗表示が変になりやすい | ReFSにはNTFSのMFTがないため、工程の意味づけが不明。長時間化・表示異常の原因になりやすい |
「Purging MFTが終わらない」報告はReFS固有とは限らない
「Purging MFTが終わらない」「%が異常（100%を超える）」という現象は、ReFSに限らず散見されます。
例として、Microsoft Q&Aにある別スレッドでは、「Purging MFT files 2933% complete」のように表示が破綻しても、単に進捗表示が不正確なだけで、空き領域が大きければ長時間かかる旨が回答されています。
SDELETE Purging MFT files 2933% complete and still going（Microsoft Q&A）
さらに、SysinternalsドキュメントのGitHub側Issueでは、exFAT（MFTが存在しないファイルシステム）でも“purging MFT”と表示されるという指摘が出ています。これは「表示名やロジックがNTFS前提のまま残っている」「ファイルシステム判定が荒い」など、SDelete側の実装・表示品質の問題が絡む可能性を示唆します。
sdelete “purges MFT” on exFAT disks（GitHub Issue #847）
したがって、ReFSで「Purging MFTが終わらない」現象を見ても、即座に「ReFSが悪い」「ディスクが壊れた」と決めつけるのは危険です。“SDeleteのPurging MFT工程が、環境次第で極端に時間がかかる／表示が破綻しやすい”という前提で切り分けるのが現実的です。
ReFSでSDeleteを使う前に押さえるべき前提
ReFSは主にWindows Server向けのシナリオで、可用性・拡張性・整合性を重視したファイルシステムです。用途として「バックアップターゲット」「仮想化」「大容量」が想定されます。
Resilient File System (ReFS) overview（Microsoft Learn）
この前提がSDeleteと衝突しやすい理由は次のとおりです。
- ReFSはバックアップ/仮想化で使われやすく、ボリュームが巨大になりがち
- ストレージがSANや仮想ディスク（VHDX/VMDK）で、実体のI/O性能や最適化が複雑になりがち
- 薄いプロビジョニングやTRIM/UNMAPの要件は、構成によってはNTFSが求められる（特にSAN）
つまり、SDeleteの「大量書き込み」「小さな書き込みを大量に発生させるPurging工程」は、ReFSを採用しやすい環境ほど“重くなりやすい”構造です。
目的別に選ぶべき現実解
SDeleteを使う動機は大きく2系統に分かれます。ここを取り違えると、不要なリスクを背負います。
| 目的 | よくある背景 | ReFSでSDeleteを使うリスク | 推奨アプローチ |
|---|---|---|---|
| 完全消去（復元不能） | 廃棄・返却、監査、機密データ対策 | ReFS対応が明言されず、結果を“保証”できない | 暗号化（BitLocker等）＋鍵破棄、媒体/アレイのSecure Erase、再構築を優先 |
| 空き領域のゼロ埋め | VHDX圧縮、Thin Provisioningの回収、ストレージアレイのゼロ検知 | Purging MFTで時間が読めない／表示が壊れる | SDeleteの“ゼロ化”機能を限定的に使う（テスト＆手順化）＋代替策も用意 |
完全消去が目的なら「SDeleteで上書き」を主軸にしない
完全消去が要件に入る場合、ReFSでSDeleteが“動いた”ことを根拠に設計しないのが安全です。理由は単純で、公式にReFS対応が明文化されていないからです。
企業運用として堅い選択肢は、次のいずれか（または組み合わせ）です。
- BitLocker等で暗号化しておき、廃棄時に回復キーを確実に破棄（論理的な“消去”を鍵で達成）
- ストレージのSecure Erase / Sanitize（SSD/NVMeやアレイの機能を使用）
- 再フォーマット＋再暗号化、あるいは用途に応じて媒体そのものを入れ替え
なお、Windows標準ツールのcipher.exeにも「削除済み領域の上書き（/w）」機能がありますが、Microsoftの説明はNTFSを前提にしています。ReFSで同様の保証を期待するのは避けたほうが安全です。
Use Cipher.exe to overwrite deleted data – Windows Server（Microsoft Learn）
空き領域のゼロ埋めが目的なら「ゼロ化に限定して」「期待値を合わせる」
VHDX/VMDKの圧縮や、アレイ側のゼロ検知で容量を回収したい場合、SDeleteが現場で使われることがあります。Veeamフォーラムでも、ReFSボリュームに対して sdelete64 -z が動作したという体験談が複数あります（ただし公式保証ではありません）。
ReFS – reclaim space on array?（Veeam Forums）
ここで大事なのは、SDeleteの公式説明上も -z は「仮想ディスク最適化に良い」 と明記されている点です。目的が「ゼロ化」なら、オプション選択を誤らないことが最初の防波堤になります。
SDelete – Sysinternals（-z Zero free space の説明）
ただし、ゼロ化が目的でも最後に「Purging MFT」が出て長引くことがあります。この工程はNTFSのMFTに基づく説明しかないため、ReFSでは“長くても驚かない”こと、そして“完了時間を読んで運用に組み込む”のが重要です。
実務向け：切り分けと再現確認のチェックリスト
「ReFSだからダメ」と決める前に、最低限この情報を揃えると、原因が急に絞れます。Sysinternalsに質問するときのテンプレとしても有効です。
環境情報の採取
- OS：Windows Serverのバージョン（2016/2019/2022/2025）と最新パッチ状況
- ReFSの配置：ローカルディスク / Storage Spaces / S2D / SAN / 仮想ディスク（VHDX/VMDK）
- ボリューム規模：容量、空き容量、割り当て単位（4K/64K）
- SDeleteのバージョン：2.02か、最新（現行ドキュメント上はv2.05）か
コマンド例：
fsutil fsinfo volumeinfo X:
Get-Volume -DriveLetter X
コントロールテスト
- 同じマシンで、NTFSの別ボリュームに対して同様の操作を実施し、Purging MFTの所要時間や進捗表示の癖を比較する
- 対象が仮想ディスクなら、裏側ストレージのスループット/レイテンシが出ているかをリソースモニターやPerfMonで確認する
「止まっている」のか「遅い」のかを見分ける
Purging MFTが長いとき、体感では“固まった”ように見えます。判断のポイントは次のとおりです。
| 観測 | 解釈 | 次のアクション |
|---|---|---|
| ディスクI/Oが継続している | 処理は進んでいる可能性が高い（表示が壊れているだけの場合も） | メンテナンス枠を確保して継続。必要ならQ&Aに事例投稿 |
| I/OがほぼゼロでCPUも低い | 待機/リトライ/ブロックの可能性 | イベントログ、ストレージ側ログ、AV/バックアップ/スナップショット干渉を確認 |
| 空き容量が急減し続ける | 一時ファイルで埋めている最中の可能性 | 想定内。ただし業務影響が出ない枠で実施 |
進捗表示が破綻する例自体は、Microsoft Q&Aでも「表示がおかしいだけで問題とは限らない」とされています。
SDELETE Purging MFT files 2933% complete and still going（Microsoft Q&A）
よくある落とし穴
「ReFSで実行できた＝ReFS対応」と誤解する
SDeleteは論理ディスクに対して実行できてしまうため、ReFSでも“開始できる”ことがあります。しかし、公式ドキュメントがNTFSのMFTを前提に工程を説明している以上、動作保証まで推定する根拠にはなりません。
SDelete – Sysinternals（How SDelete Works）
「Purging MFT＝ファイル名も含めて完全に痕跡ゼロ」と思い込む
SDeleteの公式説明には、空き領域の処理ではファイル名は消せない旨が明記されています（ディレクトリ構造の未使用領域は他ファイルに割り当てできず、上書きできないため）。
SDelete – Sysinternals（file names located in free disk space の記述）
つまり、規制・監査・フォレンジック耐性まで含めて「痕跡を消す」が要件なら、SDeleteだけで設計を完結させるのは危険です。暗号化や媒体消去と組み合わせるのが現実的です。
薄いプロビジョニング回収を「OS側のTRIM/UNMAP」でやろうとして詰まる
ReFSのTRIM/UNMAPやThin Provisioningの扱いは、構成依存です。MicrosoftのReFS概要では、SANでは薄いプロビジョニング/TRIM/UNMAP/ODXが必要ならNTFSを使うべき、と明記されています（少なくともバックアップターゲットの文脈）。
ReFS overview（Backup target / SANの注意書き）
そのため、SANや仮想基盤上では「TRIMが効かない→ゼロ化で回収を狙う」という流れになりやすく、SDeleteが選択肢に上がってきます。ただしこれはあくまで“運用上の回避策”なので、手順化・検証・ロールバックまでセットで用意しておくのが安全です。
Sysinternalsに質問するなら、こう書くと話が早い
ReFS互換性を公式に確認したい場合、Microsoft Q&AのSysinternalsタグへ投稿するのが現行の窓口です。旧SysinternalsフォーラムはMicrosoft Q&Aへ移行しています。
Sysinternals Community（窓口案内）
Sysinternals Forums移行案内（Microsoft Q&Aへ）
投稿に含めるとよい情報：
- SDeleteのバージョン（例：2.02 / 2.05）
- OSバージョン（Server 2016/2019/2022/2025）
- 対象ボリュームのファイルシステム（ReFSバージョン、クラスタサイズ）
- 実行コマンド（-c / -z、対象ドライブ）
- 「Purging MFT」で止まるスクリーンショット、またはログ
- 裏側ストレージ構成（物理ディスク、SAN、仮想ディスク、Thin provisioningの有無）
こうした情報が揃うと、単なる一般論ではなく「ReFSは非対応です」「このケースは不具合です」「この条件だと時間がかかります」といった、判断に使える回答が得られやすくなります。
まとめ
- Microsoft Q&Aの当該スレッドでは、SDelete 2.02のReFS互換性は断言されず、専用窓口へ誘導されている
- SDelete公式ドキュメントはNTFSのMFTを前提に「Purging MFT」の工程を説明しており、ReFS対応を明言していない
- Purging MFTの進捗表示が壊れる・長引く事例はReFS固有とは限らず、SDelete側の工程や表示品質が絡む可能性がある
- 完全消去が目的なら、暗号化＋鍵破棄や媒体消去など、保証しやすい手段を主軸にするのが安全
- ゼロ埋めが目的なら、SDeleteを“限定的に”使い、検証・手順化・運用枠の確保まで含めて設計する
参考リンク
- SysInternals SDelete 2.02 – Is it compatible with ReFS ?（Microsoft Q&A）
- Sysinternals Community（Microsoft Learn）
- SDelete – Sysinternals（公式ドキュメント）
- SDELETE Purging MFT files 2933% complete and still going（Microsoft Q&A）
- Use Cipher.exe to overwrite deleted data – Windows Server（Microsoft Learn）
- ReFS – reclaim space on array?（Veeam Forums）
- sdelete “purges MFT” on exFAT disks（GitHub Issue #847）
- Resilient File System (ReFS) overview（Microsoft Learn）
コメント