Pourquoi la défragmentation du lecteur C a-t-elle augmenté mon espace disque libre de 10 Go?

J'ai utilisé Defraggler pour défragmenter l'espace libre sur mon disque C: \ de 100 Go qui était plein à 85 Go. Après la défragmentation, le lecteur n'a montré que 75 Go pleins. Comment est apparue comme par magie 10 Go d'espace libre? Ai-je perdu des données?

J'ai fait un nettoyage de disque avant de défragmenter et ma corbeille n'était que d'environ 11 Mo, donc cela ne peut pas être dû au nettoyage des fichiers temporaires. Notez que j'ai défragmenté "l'espace libre" ce qui signifie qu'il aurait dû réorganiser les blocs vides pour qu'ils soient contigus.

ntfs disk-space defragment

— goweon
source

Probablement une interaction avec le cliché instantané: voir par exemple ( piriform.com/docs/defraggler/technical-information/… )

— horatio

En outre, Defraggler a une option pour vider la corbeille avant la défragmentation.

— oKtosiTe

Réponses:

Ce qui s'est probablement passé, c'est que l'opération de défragmentation a forcé Windows à supprimer certains instantanés de restauration du système. Ce serait un cas pathologique de fragmentation que la surcharge de métadonnées représente 10% de votre espace disque en plus de ce que Windows utilise normalement. même alors, je ne suis pas sûr que ce soit possible.

Je ne vois rien dans l'historique des versions de Defraggler ou dans la documentation qui indique qu'il est capable de défragmenter correctement les fichiers pour empêcher la purge des clichés instantanés. En fait, ce fil du forum de support de Defraggler indique qu'ils savent que cela se produit (il y a un message d'un administrateur du forum intitulé "Official Piriform Bug Fixer" dans le fil) mais n'indiquent pas s'ils vont le réparer ou non.

Les clichés instantanés peuvent être perdus lorsque vous défragmentez un volume : la raison en est que par défaut, VSS fonctionne avec des clusters de 16 Ko par défaut, tandis que la plupart des volumes NTFS sont formatés avec des clusters de 4 Ko. Donc, si une opération de défragmentation déplace des données qui ne sont pas un multiple d'un cluster de 16 Ko (ou la "distance" qu'elle a déplacée n'est pas un multiple de 16 Ko), alors VSS le suivra comme un changement et pourrait purger tous vos instantanés.

MSDN: défragmentation des fichiers :

Lorsque cela est possible, déplacez les données dans des blocs alignés les uns par rapport aux autres par incréments de 16 kilo-octets (Ko). Cela réduit la surcharge de copie sur écriture lorsque les clichés instantanés sont activés, car l'espace de cliché instantané est augmenté et les performances sont réduites lorsque les conditions suivantes se produisent:

La taille du bloc de demande de déplacement est inférieure ou égale à 16 Ko.

Le delta de déplacement n'est pas par incréments de 16 Ko.

La défragmentation intégrée de Vista ne fait pas cela :

Un changement qui n'est pas évident pour les utilisateurs est notre optimisation du cliché instantané pendant la défragmentation. Defrag dispose d'heuristiques spéciales pour déplacer les blocs de fichiers de manière à minimiser l'activité de copie sur écriture et la consommation de la zone de stockage des clichés instantanés. Sans cette optimisation, le processus de défragmentation accélérerait la suppression des clichés instantanés plus anciens.

— afrazier
source

Je ne connais pas la partie instantanés de cette réponse, mais je ne suis pas convaincu que la défragmentation ait libéré l'espace. La défragmentation aurait-elle pu vider votre corbeille? Sur un système de fichiers qui ne combine pas de petits fichiers en un seul cluster, je ne vois pas comment la défragmentation entraînerait un tel gain d'espace. Je pouvais imaginer que vous disposiez de 10 G d'espace disponible dans de si petits blocs que Windows ne les comptait pas, mais je n'avais jamais entendu parler de ce comportement auparavant.

— Slartibartfast

@Slartibartfast: C'est un problème si l'application n'est pas écrite correctement. Je mettrai à jour ma réponse avec plus de preuves, maintenant que je ne suis pas sur mon téléphone. :-)

— afrazier

@afrazier - bien que je pense que la réponse mise à jour de ThouArtNotDoc est une meilleure réponse générale. Je dois admettre que les clichés instantanés jouent probablement un rôle dans la situation du PO. J'ai également trouvé ceci: "Si vous prévoyez de défragmenter des volumes sur lesquels les clichés instantanés sont activés, il est recommandé d'utiliser une taille de cluster (ou unité d'allocation) de 16 Ko ou plus. Sinon, le nombre de modifications provoquées par le processus de défragmentation peut entraîner la suppression des clichés instantanés plus rapidement que prévu. " - MS: "Conception d'une stratégie de cliché instantané

— Ƭᴇcʜιᴇ007

@afrazier: confirmé. Tous les points de restauration du système précédents ont disparu. Dans la configuration, j'ai 12% défini comme l'espace maximum autorisé pour les clichés instantanés, donc 10 Go n'est pas déraisonnable. D'un autre côté, je viens d'installer un jeu de 9 Go, qui aurait pu simplement écraser les points de restauration précédents.

— goweon

@firebat: L'espace utilisé par la restauration du système est pour suivre les modifications apportées aux fichiers existants (instantanés), pas les nouveaux. L'installation d'un nouveau jeu n'aurait pas d'impact sur l'espace de restauration du système, mais un gros patch pourrait le faire.

— afrazier

Chaque fragment doit être suivi quelque part. Cela prend de l'espace de stockage (dans la plomberie du système de fichiers, pas dans les éléments auxquels vous êtes censé accéder directement).

Un exemple: supposons que vous ayez un seul fichier avec 1000 fragments. Ainsi, votre fichier est stocké à travers une collection de blocs aléatoires. Plutôt que dans un seul bloc continu. Cela signifie que le fichier fragmenté nécessite 1000 fois plus d'espace de stockage dans la plomberie du système de fichiers, ne serait-ce que pour stocker des adresses pour chaque fragment. La plomberie du système de fichiers conserve peu de dictionnaires / bases de données / cartes / tables / liste à l'emplacement de chaque fragment du fichier. Ainsi, pour la plomberie du système de fichiers, le stockage d'une liste d'un pointeur de fragment unique ne nécessite pas beaucoup d'espace, par rapport à une liste de 1000 pointeurs de fragment.

Mais bon, je me trompe peut-être ...

Modifier: informations complémentaires d'ici :

Lorsqu'un flux de données non résident est trop fragmenté, de sorte que sa carte d'allocation effective ne peut pas s'intégrer entièrement dans l'enregistrement MFT, la carte d'allocation peut également être stockée en tant que flux non résident, avec juste un petit flux résident contenant l'allocation indirecte. mapper à la carte d'allocation effective des non-résidents du flux de données des non-résidents.

Traduction: Si vous avez une forte fragmentation, les hypothèses générales de la plomberie du système de fichiers ne s'appliqueront pas. En tant que tel, le FS doit prendre des mesures pour s'adapter à la fragmentation et finir par coûter de l'espace de stockage supplémentaire, juste pour gérer les fragments. Exactement ma supposition dès le départ.

Edit: Compte tenu de ce qui précède, il semble toujours que 10 Go soient perdus juste à cause de la fragmentation des fichiers, c'est fou. Je parie que lors de la défragmentation, vous aviez une corruption de système de fichiers commune qui a été corrigée automatiquement. Je pense que non seulement vous avez eu une fragmentation massive, mais aussi des fichiers partiellement supprimés occupant de l'espace de stockage. Il aurait été agréable de voir un journal scandisk de cette défragmentation (ou une série de scandisk avant la défragmentation)

— James T Snell
source

PS - cela a dû être une fragmentation hardcore.

— James T Snell

Je ne sais pas si c'est une raison valable pour une telle augmentation de la consommation de stockage après la défragmentation. Mais je l'ai remarqué à plusieurs reprises, si vous avez un point de restauration système qui est assez ancien (cela ne se produit généralement pas si vous exécutez régulièrement l'utilitaire de nettoyage de disque), puis vous défragmentez après que beaucoup de données sont collectées sur le lecteur C, la consommation de mémoire augmente de nulle part, mais si vous supprimez ce point de restauration, il nettoie le stockage occupé. Eh bien, techniquement, cela n'a peut-être aucun sens, mais cela m'est arrivé plusieurs fois, car les heures supplémentaires, les points de restauration prennent de la mémoire.

— Kushal

Je ne sais pas, 10G semble beaucoup, mais IME, les disques très pleins ont tendance à se fragmenter beaucoup plus rapidement que les disques moins fragmentés. S'il était à> 85% auparavant (car il voulait dire 85 Go mais 100 Go de disque), et peut-être plus plein entre-temps, il aurait pu avoir une fragmentation spectaculairement élevée et des performances horribles.

— Bernd Haug

À moins que la taille de bloc de ce volume ne soit obscurément élevée, je ne peux personnellement pas croire que 10 Go d'espace soient libérés simplement en ne suivant pas les fragments. Avec une taille de bloc de 4096 Ko et en supposant que chaque fragment nécessite un bloc complet juste pour le suivi (ce qui est faux), cela nécessiterait 2,5 millions de fragments anciennement suivis mais plus pour libérer autant d'espace.

— CarlF

@Doc - un pointeur ne prendra pas un bloc entier. Si (comme cela est probable) chaque bloc d'allocation est composé de plusieurs secteurs, vous avez besoin de moins de pointeurs car il y a moins de blocs à suivre pour vos données - donc la surcharge maximale possible pour suivre tous les fragments sera bien inférieure à 3%. Je ne connais pas les détails exacts de NTFS, mais avec les systèmes de classement FAT (relativement inefficaces), vous ne pouviez toujours pas obtenir 10% de surcharge pour la table d'allocation de fichiers (ces pointeurs de suivi des fragments) qui a donné son nom à FAT.

— Steve314