Dziennik NTFS: czym jest i dlaczego rośnie

Dwa dzienniki, dwa zadania

Pierwszy to $LogFile, własny dziennik z wyprzedzeniem zapisu (write-ahead) dla metadanych NTFS. Zanim NTFS zmieni cokolwiek strukturalnego — rozmiar pliku, jego położenie na dysku, wpis w katalogu — najpierw zapisuje zamierzoną zmianę w $LogFile, tak aby utrata zasilania w trakcie operacji zostawiła wolumin montowalny i w zasadzie nienaruszony. Ma odgórny limit i zapętla się w miejscu, od kilku do kilkudziesięciu MB; nigdy nim nie zarządzasz i żadne narzędzie do sprzątania nie powinno go ruszać.

Drugi to ten, który ludzie faktycznie spotykają: $UsnJrnl:$J, dziennik zmian USN (Update Sequence Number), chronologiczny zapis zmian na woluminie — pliki utworzone, przemianowane, usunięte, zapisane. Istnieje po to, by aplikacje nie musiały skanować całego dysku, żeby dowiedzieć się, co się zmieniło od ostatniego spojrzenia.

• indeksator Windows Search — wie dokładnie, co przeindeksować
• oprogramowanie do kopii zapasowych — wykrywa zmienione pliki bez przeszukiwania całego drzewa
• klienci synchronizacji chmurowej — wysyłają tylko to, co faktycznie się zmieniło
• narzędzia natychmiastowego wyszukiwania jak Everything — trzymają indeks na bieżąco
• korporacyjne agenty DLP i eDiscovery — audytują zdarzenia na plikach
• niektóre antywirusy — śledzą aktywność plików między pełnymi skanami

Dlaczego rośnie i kiedy to ma znaczenie

Dziennik USN rośnie wraz z ruchem zmian: kompilacje, pamięci podręczne przeglądarek, reorganizowane biblioteki zdjęć — każde utworzenie, przemianowanie i usunięcie dopisuje mały rekord. Jego maksymalny rozmiar jest konfigurowalny i aplikacje mogą go podnosić; agent synchronizacji czy kopii zapasowych może wręcz zażądać dużego dziennika, żeby nie przegapić żadnej zmiany z czasu swojej nieobecności. Gdy dziennik osiągnie limit, zapętla się: najstarsze rekordy są nadpisywane. Innymi słowy, duży dziennik to zwykle zamierzone ustawienie, nie wyciek — a widnieje jako „niewyjaśnione” miejsce, bo mieszka w metadanych NTFS, tam gdzie menedżery plików nie zaglądają.

Czego nie robi, to nie spowalnia. Dopisywanie to malutkie sekwencyjne zapisy, a czytelnicy — wyszukiwanie, backup, synchronizacja — bez niego spaliłyby znacznie więcej CPU na ponownym skanowaniu dysku. Koszt dziennika to miejsce, nie szybkość.

Co robić (a czego nie)

Zazwyczaj: nic. Jeśli chcesz zobaczyć swój, uruchom jako administrator fsutil usn queryjournal C: — wypisze identyfikator dziennika i statystyki rekordów. Jeśli autentycznie potrzebujesz miejsca i możesz sobie pozwolić na burzę ponownych skanów, fsutil usn deletejournal /D C: jest bezpieczne: usuwa rekordy zmian, nie Twoje pliki, a dziennik zostaje utworzony od nowa. Spodziewaj się, że Search i narzędzia synchronizacji zaraz potem wykonają pełny reskan — jednorazowy skok CPU i aktywności dysku, który mocno podważa sens przedsięwzięcia.

Czego nie wolno robić nigdy, to polować na $LogFile: to metadane, nie plik, i nic dostępnego z poziomu użytkownika nie usunie go bez łamania woluminu. Jeśli Twój dziennik urósł do gigantycznych rozmiarów, produktywne pytanie nie brzmi „jak go zmniejszyć”, tylko „która aplikacja podniosła limit” — odpowiedź powie Ci, czy to narzędzie backupu, klient synchronizacji, czy coś, o czym zapomniałeś, że działa.

Pytania i odpowiedzi

Przeczytaj także