Pourquoi la défragmentation du lecteur C a-t-elle augmenté mon espace disque disponible de 10 Go?
J'ai utilisé Defraggler pour défragmenter l'espace libre sur mon lecteur C:\de 100 Go, qui était plein à 85 Go. Après la défragmentation, le disque ne contenait que 75 Go de mémoire. Comment 10 Go d'espace libre sont-ils apparus comme par magie? Ai-je perdu des données?
Avant de défragmenter, j'ai nettoyé le disque et ma corbeille ne faisait que 11 Mo environ. Cela ne peut donc pas être dû au nettoyage des fichiers temporaires. Notez que j'ai défragmenté "espace libre", ce qui signifie qu'il aurait dû réarranger les blocs vides pour qu'ils soient contigus.
Ce qui est probablement arrivé, c’est que l’opération de défragmentation a obligé Windows à supprimer certains instantanés de restauration du système. Ce serait un cas pathologique de fragmentation de faire en sorte que la surcharge de métadonnées représente 10% de votre espace disque par rapport à ce que Windows utilise normalement. même dans ce cas, je ne suis pas sûr que ce soit possible.
Dans l'historique de la version de Defraggler, ni dans la documentation, je ne vois rien 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 d'assistance de Defraggler indique qu'ils savent que cela se produit (un message d'un administrateur du conseil intitulé "Official Piriform Bug Fixer" dans le fil), mais n'indique pas s'ils le font ou non. allons le réparer.
Des clichés instantanés peuvent être perdus lors de la défragmentation d'un volume : Cela s'explique par le fait que VSS fonctionne par défaut avec des clusters de 16 Ko alors que la plupart des volumes NTFS sont formatés avec des clusters de 4 Ko. Ainsi, 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 que la "distance" ne soit pas un multiple de 16 Ko), alors VSS le suivra comme un changement et risque de purger toutes vos données. instantanés.
MSDN: Défragmentation de fichiers :
Si possible, déplacez les données en blocs alignés les uns par rapport aux autres, par incréments de 16 kilo-octets (Ko). Cela réduit le temps de traitement de la copie en écriture lorsque les copies fantômes sont activées, car l'espace de copie fantôme est augmenté et les performances réduites lorsque les conditions suivantes se produisent:
- La taille du bloc de la 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.
Defrag intégré à Vista ne le fait pas :
L’optimisation des clichés instantanés lors de la défragmentation est un changement qui n’est pas évident pour les utilisateurs. 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 de clichés instantanés. Sans cette optimisation, le processus de défragmentation accélérerait la suppression d'anciens clichés instantanés.
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é via 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 tuyauterie du système de fichiers, ne serait-ce que pour stocker les adresses de chaque fragment. La plomberie du système de fichiers conserve peu de dictionnaires/bases de données/cartes/tableaux/listes à l'emplacement de chaque fragment du fichier. Ainsi, pour la plomberie du système de fichiers, stocker une liste d'un seul pointeur de fragment n'a pas besoin de beaucoup d'espace, comparé à une liste de 1000 pointeurs de fragment.
Mais bon, peut-être que je me trompe ...
Edit: informations de support 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 tenir entièrement dans l'enregistrement MFT, la carte d'allocation peut également être stockée en tant que flux non-résident, avec seulement un petit flux résident contenant l'allocation indirecte. mappez sur la carte d'allocation efficace pour les non-résidents du flux de données non-résident.
Traduction: Si vous avez une fragmentation importante, les hypothèses de cas 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 gérer la fragmentation et finalement coûter de l'espace de stockage supplémentaire, uniquement pour gérer les fragments. Exactement ce que je pense de la première place.
Edit: Compte tenu de ce qui précède, il semble toujours que 10 Go soient perdus juste pour fragmenter un fichier, c'est dingue. Je parie que lors de la défragmentation, vous avez eu une corruption commune du système de fichiers qui a été corrigée automatiquement. Je pense que non seulement vous avez eu une fragmentation massive, mais également 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)