Qu'est-ce que le journal NTFS et pourquoi il ne cesse de grossir

Deux journaux, deux métiers

Le premier est $LogFile, le journal d'écriture différée de NTFS pour ses métadonnées. Avant que NTFS ne modifie quoi que ce soit de structurel — la taille d'un fichier, sa position sur le disque, une entrée de répertoire — il écrit d'abord le changement prévu dans $LogFile, pour qu'une coupure de courant en pleine opération laisse le volume montable et grosso modo intact. Il est plafonné par conception et tourne en rond, de quelques Mo à quelques dizaines de Mo ; vous ne l'administrez jamais, et aucun nettoyeur ne devrait y toucher.

Le second est celui que les gens rencontrent vraiment : $UsnJrnl:$J, le journal des modifications USN (Update Sequence Number), une chronologie de ce qui arrive au volume — fichiers créés, renommés, supprimés, écrits. Il existe pour que les applications n'aient pas à rescanner tout un disque pour savoir ce qui a changé depuis leur dernier passage.

• l'indexeur de la Recherche Windows — sait exactement quoi réindexer
• les logiciels de sauvegarde — repèrent les fichiers modifiés sans parcourir tout l'arbre
• les clients de synchronisation cloud — n'envoient que ce qui a réellement bougé
• les outils de recherche instantanée comme Everything — gardent leur index à jour
• les agents DLP et eDiscovery d'entreprise — auditent les événements de fichiers
• certains antivirus — suivent l'activité des fichiers entre deux analyses complètes

Pourquoi il grossit, et quand ça compte

Le journal USN grossit avec le trafic de modifications : compilations, caches de navigateur, photothèques réorganisées — chaque création, renommage et suppression ajoute un petit enregistrement. Sa taille maximale est configurable, et les applications peuvent l'augmenter ; un agent de synchronisation ou de sauvegarde demande un grand journal précisément pour ne rater aucune modification pendant son absence. Arrivé à son plafond, le journal boucle : les enregistrements les plus anciens sont écrasés. Autrement dit, un gros journal est en général un réglage délibéré, pas une fuite — et il apparaît comme de l'espace utilisé « inexpliqué » parce qu'il vit dans les métadonnées NTFS, là où les gestionnaires de fichiers ne regardent pas.

Ce qu'il ne fait pas, c'est ralentir quoi que ce soit. Les ajouts sont de minuscules écritures séquentielles, et les lecteurs — recherche, sauvegarde, synchronisation — brûlerient bien plus de CPU à rescanner le disque sans lui. Le coût du journal, c'est de l'espace, pas de la vitesse.

Quoi faire (et quoi ne pas faire)

D'ordinaire : rien. Pour voir le vôtre, lancez fsutil usn queryjournal C: en administrateur — il rapporte l'ID du journal et des statistiques d'enregistrements. Si vous avez réellement besoin de la place et pouvez vous offrir une tempête de rescans, fsutil usn deletejournal /D C: est sûr : il supprime les enregistrements de modifications, pas vos fichiers, et le journal se recrée. Attendez-vous à un rescan complet de la Recherche et de la synchronisation juste après — un pic unique de CPU et de disque qui vide en grande partie l'intérêt de la manœuvre.

Ce qu'il ne faut jamais faire, c'est partir à la chasse à $LogFile : c'est une métadonnée, pas un fichier, et rien côté utilisateur ne peut le supprimer sans casser le volume. Si votre journal a énormément grossi, la question productive n'est pas « comment le réduire » mais « quelle application a relevé le plafond » — cette réponse vous dit si c'est votre sauvegarde, votre client de sync, ou quelque chose dont vous aviez oublié qu'il tournait.

Questions et réponses

À lire ensuite