Cos'è il journal NTFS e perché continua a crescere

Due registri, due lavori

Il primo è $LogFile, il write-ahead journal che NTFS tiene per i propri metadati. Prima di toccare qualsiasi cosa strutturale — la dimensione di un file, la sua posizione sul disco, una voce di directory — NTFS scrive la modifica prevista in $LogFile, così un blackout a metà operazione lascia il volume montabile e più o meno intatto. Ha un tetto per progetto e si sovrascrive su se stesso, da pochi MB a qualche decina; non lo gestisce nessuno e nessun pulitore dovrebbe toccarlo.

Il secondo è quello che la gente incontra davvero: $UsnJrnl:$J, il change journal USN (Update Sequence Number), la cronologia delle modifiche del volume — file creati, rinominati, cancellati, riscritti. Esiste perché le applicazioni non debbano riscansionare un intero disco per sapere cosa è cambiato dall'ultima occhiata.

• l'indicizzatore di Windows Search — sa esattamente cosa reindicizzare
• il software di backup — individua i file modificati senza attraversare l'intero albero
• i client di sincronizzazione cloud — caricano solo ciò che è davvero cambiato
• gli strumenti di ricerca istantanea come Everything — tengono l'indice aggiornato
• gli agent DLP ed eDiscovery aziendali — controllano gli eventi sui file
• alcuni antivirus — tracciano l'attività dei file tra le scansioni complete

Perché cresce, e quando conta

Il journal USN cresce col traffico di modifiche: compilazioni, cache dei browser, librerie di foto riorganizzate — ogni creazione, rinomina e cancellazione accoda un piccolo record. La dimensione massima è configurabile e le applicazioni possono alzarla; un agente di sync o di backup può chiedere un journal grande apposta per non perdersi nessuna modifica avvenuta mentre era offline. Quando il journal raggiunge il tetto, si avvolge: i record più vecchi vengono sovrascritti. In altre parole, un journal grande è di solito un'impostazione voluta, non una perdita — e compare come spazio usato «inspiegabile» perché vive nei metadati NTFS, dove i file manager non vedono.

Quello che non fa è rallentare nulla. Gli accodamenti sono minuscole scritture sequenziali, e i lettori — ricerca, backup, sync — senza di esso brucerebbero molta più CPU a riscansionare il disco. Il costo del journal è spazio, non velocità.

Cosa fare (e cosa no)

Di solito: niente. Se vuoi vedere il tuo, da amministratore esegui fsutil usn queryjournal C: — riporta l'ID del journal e le statistiche dei record. Se davvero ti serve spazio e puoi permetterti una tempesta di riscansioni, fsutil usn deletejournal /D C: è sicuro: cancella i record delle modifiche, non i tuoi file, e il journal viene ricreato. Metti in conto che Search e i tool di sync faranno subito una riscansione completa — un picco una tantum di CPU e disco che rischia di vanificare lo scopo.

Ciò che non devi mai fare è andare a caccia di $LogFile: è metadato, non un file, e niente di accessibile all'utente può cancellarlo senza rompere il volume. Se il tuo journal è diventato enorme, la domanda utile non è «come lo riduco» ma «quale applicazione ha alzato il tetto» — la risposta ti dice se si tratta del tuo tool di backup, del client di sincronizzazione o di qualcosa che avevi dimenticato essere in esecuzione.

Domande e risposte

Da leggere dopo