O que é o diário NTFS e por que ele não para de crescer

Dois registros, dois ofícios

O primeiro é o $LogFile, o journal de escrita antecipada do próprio NTFS para metadados. Antes de o NTFS mudar qualquer coisa estrutural — o tamanho de um arquivo, sua posição no disco, uma entrada de diretório — ele escreve primeiro a mudança pretendida no $LogFile, para que um corte de energia no meio da operação deixe o volume montável e quase intacto. Ele é limitado por design e gira em círculo, de poucos a algumas dezenas de MB; você nunca o administra, e nenhuma ferramenta de limpeza deveria encostar nele.

O segundo é o que as pessoas de fato encontram: $UsnJrnl:$J, o diário de alterações USN (Update Sequence Number), um registro cronológico do que acontece no volume — arquivos criados, renomeados, apagados, gravados. Ele existe para que os aplicativos não precisem reescanear um disco inteiro para descobrir o que mudou desde a última olhada.

o indexador da Pesquisa do Windows — sabe exatamente o que reindexar
softwares de backup — detectam arquivos alterados sem varrer a árvore toda
clientes de sincronização em nuvem — sobem só o que realmente mexeu
ferramentas de busca instantânea como o Everything — mantêm o índice em dia
agentes corporativos de DLP e eDiscovery — auditam eventos de arquivos
alguns antivírus — acompanham a atividade de arquivos entre varreduras completas

Por que ele cresce, e quando isso importa

O diário USN cresce com o tráfego de mudanças: builds, caches de navegador, acervos de fotos reorganizados — cada criação, renomeação e exclusão acrescenta um registro pequeno. O tamanho máximo é configurável, e os aplicativos podem aumentá-lo; um agente de sincronização ou backup pede um diário grande justamente para não perder mudanças enquanto esteve desligado. Ao chegar ao teto, o diário dá a volta: os registros mais antigos são sobrescritos. Noutras palavras, um diário grande costuma ser ajuste deliberado, não vazamento — e aparece como espaço usado "inexplicável" porque mora nos metadados do NTFS, onde os gerenciadores de arquivos não olham.

O que ele não faz é desacelerar coisa alguma. As inclusões são escritas sequenciais minúsculas, e os leitores — busca, backup, sincronização — queimariam muito mais CPU reescaneando o disco sem ele. O custo do diário é espaço, não velocidade.

O que fazer (e o que não fazer)

Normalmente: nada. Para ver o seu, execute fsutil usn queryjournal C: como administrador — o comando devolve o ID do diário e estatísticas de registros. Se você precisa mesmo do espaço e pode bancar uma tempestade de reescaneamentos, fsutil usn deletejournal /D C: é seguro: apaga os registros de alterações, não os seus arquivos, e o diário é recriado. Prepare-se para um reescaneamento completo da Pesquisa e da sincronização logo depois — um pico único de CPU e disco que mata boa parte da graça da operação.

O que você nunca deve fazer é sair à caça do $LogFile: ele é metadado, não arquivo, e nada do lado do usuário consegue apagá-lo sem quebrar o volume. Se o seu diário cresceu demais, a pergunta produtiva não é "como encolher", e sim "qual aplicativo subiu o teto" — a resposta revela se foi o seu backup, o seu cliente de sincronização ou algo que você tinha esquecido que estava rodando.

Perguntas e respostas

É seguro apagar o diário USN?

É. fsutil usn deletejournal /D C: remove apenas os registros de alterações, não os seus arquivos. O diário é recriado, e a Pesquisa e a sincronização reescaneiam — espere um pico único de CPU e disco.

O diário NTFS desacelera o computador?

Não. Escrever no diário é um fluxo de inclusões sequenciais minúsculas. Você paga em espaço de disco, não em velocidade — sem ele, busca, backup e sincronização queimariam muito mais CPU reescaneando tudo.