NTFS ジャーナルとは何か、そして増え続ける理由

それはどのフォルダーにも属さない領域として現れます。ドライブは 40 GB 使用と報告し、ファイルの合計は 36 GB。この差の中に 2 つの NTFS ログが住んでいます。1 つはデータを守り、もう 1 つはアプリケーションに仕え、「増え続ける」のはそのうちの 1 つだけです。

2 つのログ、2 つの役割

1 つ目は $LogFile。NTFS がメタデータのために持つライトアヘッドジャーナルです。NTFS は構造的な変更を行う前に——ファイルのサイズ、ディスク上の位置、ディレクトリ項目など——意図した変更をまず $LogFile に書き込みます。そのおかげで操作の途中で電源が落ちても、ボリュームはマウント可能でほぼ無傷のままです。設計上上限が決まっていて同じ場所を巡回し、数 MB〜数十 MB 程度。自分で管理することはなく、クリーンアップツールが触れるべきものでもありません。

2 つ目は実際に目にする機会のある $UsnJrnl:$J。USN(Update Sequence Number)変更ジャーナルで、ボリューム上の変更——作成、名前変更、削除、書き込み——を時系列で記録します。アプリケーションが前回見てからの変更を知るためにディスク全体を再スキャンしなくて済むよう、これが存在します。

Windows Search のインデクサー——再インデックス化すべき対象を正確に把握
バックアップソフト——ツリー全体を走査せず変更ファイルを検出
クラウド同期クライアント——実際に動いたものだけをアップロード
Everything などの即時検索ツール——インデックスを最新に保つ
企業の DLP / eDiscovery エージェント——ファイルイベントを監査
一部のアンチウイルス——フルスキャンの合間にファイル活動を追跡

増える理由と、問題になる場面

USN ジャーナルは変更の交通量とともに増えます。コンパイル、ブラウザーのキャッシュ、整理し直される写真ライブラリー——作成、名前変更、削除のたびに小さなレコードが追記されます。最大サイズは設定可能で、アプリケーションから引き上げることもできます。同期やバックアップのエージェントは、オフライン中の変更を決して取り逃がさないために、あえて大きなジャーナルを要求することがあります。上限に達するとラップし、最も古いレコードが上書きされます。つまり大きなジャーナルは通常、意図的な設定であってリークではありません。そして NTFS メタデータの中、ファイルマネージャーの目の届かない場所にいるため、「説明のつかない」使用領域として現れるのです。

やらないのは、何かを遅くすることです。追記はごく小さな逐次書き込みで、読み手である検索・バックアップ・同期は、ジャーナルなしでディスクを再スキャンすれば遥かに多くの CPU を燃やすことになります。ジャーナルのコストは容量であって速度ではありません。

すべきこと(とすべきでないこと)

通常は何もしないことです。自分のものを見たければ、管理者として fsutil usn queryjournal C: を実行します。ジャーナル ID とレコード統計が表示されます。どうしても容量が必要で、再スキャンの嵐を許容できるなら、fsutil usn deletejournal /D C: は安全です。削除されるのは変更レコードだけで、ファイルではなく、ジャーナルは作り直されます。ただし直後に検索と同期ツールがフルスキャンを行い、CPU とディスクが一時的に急増します。それは目的をほぼ無に帰すものです。

絶対にしてはいけないのは $LogFile を狩ることです。あれはファイルではなくメタデータで、ユーザー側から削除すればボリュームを壊す以外に結果はありません。ジャーナルが巨大化した場合、生産的な問いは「縮めるには」ではなく「上限を引き上げたのはどのアプリか」です。その答えは、犯人がバックアップツールなのか、同期クライアントなのか、動いていることを忘れていた何かなのかを教えてくれます。