¿Por qué la desfragmentación de la unidad C aumentó mi espacio libre en disco en 10 GB?

Utilicé Defraggler para desfragmentar el espacio libre en mi unidad C: \ de 100 GB que tenía 85 GB llenos. Después de la desfragmentación, la unidad mostró solo 75 GB llenos. ¿Cómo aparecieron mágicamente 10 GB de espacio libre? ¿Perdí algún dato?

Hice una limpieza de disco antes de desfragmentar y mi basura solo tenía unos 11 MB, por lo que no puede ser debido a la limpieza de los archivos temporales. Tenga en cuenta que defragmenté el "espacio libre", lo que significa que debería haber reorganizado los bloques vacíos para que fueran contiguos.

Lo que probablemente sucedió es que la operación de desfragmentación obligó a Windows a descartar algunas instantáneas de restauración del sistema. Sería un caso patológico de fragmentación causar que la sobrecarga de metadatos sea un 10% del espacio total de su unidad además de lo que normalmente usa Windows. incluso entonces, no estoy seguro de que sea posible.

No veo nada en el historial de versiones o la documentación de Defraggler que indique que puede desfragmentar correctamente los archivos para evitar la purga de instantáneas. De hecho, este hilo del foro de soporte de Defraggler indica que saben que está sucediendo (hay una publicación de un administrador de la junta etiquetada como "Arreglador oficial de errores piriformes" en el hilo) pero no indican si van a solucionarlo o no.

Las instantáneas pueden perderse al desfragmentar un volumen : la razón por la que esto sucede es que, de manera predeterminada, VSS funciona con clústeres de 16 KB de manera predeterminada, mientras que la mayoría de los volúmenes NTFS están formateados con clústeres de 4 KB. Entonces, si una operación de desfragmentación está moviendo datos que no son múltiplos de un clúster de 16 KB (o la "distancia" que se mueve no es un múltiplo de 16 KB), entonces VSS lo rastreará como un cambio y podría purgar todos sus instantáneas

MSDN: Desfragmentación de archivos :

Cuando sea posible, mueva los datos en bloques alineados entre sí en incrementos de 16 kilobytes (KB). Esto reduce la sobrecarga de copia en escritura cuando las instantáneas están habilitadas, porque el espacio de instantáneas aumenta y el rendimiento se reduce cuando se producen las siguientes condiciones:

• El tamaño del bloque de solicitud de movimiento es menor o igual a 16 KB.
• El movimiento delta no está en incrementos de 16 KB.

La desfragmentación integrada de Vista no hace esto :

Un cambio que no es obvio para los usuarios es nuestra optimización de instantáneas durante la desfragmentación. Defrag tiene una heurística especial para mover bloques de archivos de manera que se minimice la actividad de copia en escritura y el consumo del área de almacenamiento de instantáneas. Sin esta optimización, el proceso de desfragmentación aceleraría la eliminación de las instantáneas más antiguas.

Cada fragmento tiene que ser rastreado en alguna parte. Eso ocupa espacio de almacenamiento (dentro de la plomería del sistema de archivos, no cosas a las que debes acceder directamente).

Un ejemplo: supongamos que tiene un solo archivo con 1000 fragmentos. Por lo tanto, su archivo se almacena a través de una colección de bloques aleatorios. En lugar de en un solo bloque continuo. Esto significa que el archivo fragmentado requiere 1000 veces más espacio de almacenamiento dentro de la tubería del sistema de archivos, aunque solo sea para almacenar direcciones para cada fragmento. La plomería del sistema de archivos mantiene pequeños diccionarios / bases de datos / mapas / tablas / listas en la ubicación de cada fragmento del archivo. Por lo tanto, para la plomería del sistema de archivos, almacenar una lista de un puntero de fragmento único no necesita mucho espacio, en comparación con una lista de 1000 punteros de fragmento.

Pero bueno, tal vez me equivoque ...

Editar: información de apoyo desde aquí :

Cuando un flujo de datos no residente está demasiado fragmentado, de modo que su mapa de asignación efectivo no puede caber completamente dentro del registro MFT, el mapa de asignación también puede almacenarse como un flujo no residente, con solo un pequeño flujo residente que contiene la asignación indirecta asignar al mapa de asignación efectivo de no residentes del flujo de datos de no residentes.

Traducción: si tiene una gran fragmentación, no se aplicarán los supuestos generales del caso de la plomería del sistema de archivos. Como tal, el FS debe tomar medidas para acomodar la fragmentación y terminar costando espacio de almacenamiento adicional, solo para administrar los fragmentos. Exactamente mi suposición desde el primer lugar.

Editar: Teniendo en cuenta lo anterior, todavía parece que perder 10GB solo por fragmentación de archivos es una locura. Apuesto a que durante la desfragmentación, tuvo algún daño común en el sistema de archivos que se corrigió automáticamente. Creo que no solo tuvo una fragmentación masiva, sino que también eliminó parcialmente archivos que ocupaban espacio de almacenamiento. Hubiera sido agradable ver un registro de scandisk de esa desfragmentación (o una ejecución de scandisk antes de la desfragmentación)