Що таке журнал 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 не варто ніколи: це метадані, а не файл, і нічого користувацького не може видалити його, не зламавши том. Якщо ваш журнал розпух, слушне питання не «як його втиснути», а «хто підняв межу» — відповідь підкаже, чи винний ваш бекап, ваш синхронізатор чи те, про що ви забули, що воно працює.

Питання та відповіді

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