Что такое журнал NTFS и почему он постоянно растёт

Два журнала — две работы

Первый журнал — $LogFile, собственный журнал упреждающей записи NTFS для метаданных. Прежде чем NTFS меняет что-то структурное — размер файла, его размещение на диске, запись в каталоге, — намеченное изменение сначала пишется в $LogFile, чтобы обрыв питания посреди операции оставил том монтируемым и почти целым. Он ограничен по замыслу и пишется по кругу, от нескольких до десятков мегабайт; вы им не управляете, и ни один чистильщик не должен его трогать.

Второй — тот, с которым люди реально встречаются: $UsnJrnl:$J, журнал изменений USN (Update Sequence Number), хронологическая запись событий тома — файлы созданы, переименованы, удалены, записаны. Он существует, чтобы программам не приходилось пересканировать весь диск ради ответа на вопрос «что изменилось с прошлого раза».

• индексатор поиска Windows — знает, что именно переиндексировать
• программы резервного копирования — находят изменения без обхода всего дерева
• облачные синхронизаторы — загружают только то, что реально поменялось
• инструменты мгновенного поиска вроде Everything — держат индекс актуальным
• корпоративные агенты DLP и eDiscovery — аудит файловых событий
• некоторые антивирусы — отслеживают активность между полными проверками

Почему он растёт и когда это имеет значение

Журнал USN растёт вместе с потоком изменений: сборки проектов, кеши браузеров, реорганизация фотоархивов — каждое создание, переименование и удаление дописывает маленькую запись. Его максимальный размер настраивается, и приложения могут его поднимать: агент синхронизации или резервного копирования запрашивает большой журнал ровно затем, чтобы не пропустить изменения за время своего отсутствия. Дойдя до предела, журнал пишется по кругу: старые записи затираются. Иными словами, большой журнал — обычно осознанная настройка, а не утечка, а «необъяснимым» местом он кажется потому, что живёт в метаданных NTFS, куда файловые менеджеры не заглядывают.

Чего он точно не делает — не тормозит. Дописывания — крошечные последовательные записи, а читатели — поиск, бэкапы, синхронизация — сожгли бы куда больше процессора на пересканирование диска без него. Цена журнала — место, а не скорость.

Что делать (и чего не делать)

Обычно — ничего. Хотите взглянуть на свой — выполните fsutil usn queryjournal C: от администратора: команда покажет идентификатор журнала и статистику записей. Если место позарез нужно и вы готовы к буре пересканирования, безопасна команда fsutil usn deletejournal /D C: — она удаляет записи об изменениях, а не ваши файлы, и журнал создаётся заново. Готовьтесь к полной пересборке индексов поиском и синхронизацией сразу после — разовому всплеску процессора и диска, который во многом обнуляет смысл затеи.

А вот охотиться за $LogFile не нужно никогда: это метаданные, а не файл, и ничто пользовательское не может удалить его, не сломав том. Если ваш журнал распух, правильный вопрос не «как его ужать», а «кто поднял лимит» — ответ подскажет, виноват ли ваш бэкап, ваш синхронизатор или то, о чём вы забыли, что оно работает.

Вопросы и ответы

Читайте также