¿Qué algoritmo de asignación de bloques usa NTFS?

En Windows XP 64, descargué un archivo de 1.2 GB y terminó fragmentado, como muestra la imagen. Desafortunadamente, antes de tomar la instantánea de Piriform Defraggler, desfragmenté los otros archivos, por lo que no puede ver el estado exacto en el momento en que se escribió el archivo. Sin embargo, el disco estaba todo el tiempo tan vacío como ahora (25% usado) y apenas fragmentado.

¿Qué algoritmo de asignación de bloques usa NTFS? Parece aleatorio o quizás ponerlo donde realmente se encuentra la cabeza del disco.

ACTUALIZAR:

Esto es lo que sucedió hoy después de escribir 67 MiB de un nuevo archivo. Se dividió en 731 fragmentos, tamaño promedio de solo 95 KiB. El archivo se usó para llenar algunos huecos, pero no todos, tampoco utiliza el enorme espacio libre continuo. Extraño, ¿no es así?

ACTUALIZACIÓN 2:

A diferencia de PC Guru , realmente no creo que Opera sea el culpable. Creo que (a diferencia de Google Chrome) no le dice a Windows el tamaño esperado, sin embargo, hay muchos casos en que no es posible y es responsabilidad del sistema operativo manejarlo de manera sensata. La siguiente imagen muestra lo que sucedió después de un par de días sin hacer casi nada en esta partición: el directorio TEMP y todos mis datos (excepto los administrados por Windows) se encuentran en otro lugar. Windows parece no usar SetEndOfFiley fragmenta sus propios archivos de una manera terrible (600 fragmentos para un par de archivos pequeños de aproximadamente 40 MB). NTFS no parece usar el primer sector disponible, ya que nuevamente hay archivos en el medio y también cerca del final del disco bastante vacío (uso del 23%),

IIRC, el sistema de archivos NTFS intenta asignar el archivo en un almacenamiento contiguo. Sin embargo, solo puede hacerlo si el sistema de archivos conoce el tamaño del archivo. Si abre un archivo y comienza a escribir en él, escribirá en el "mejor" lugar para que quepa el archivo (generalmente hacia el exterior del plato). Pero ese "mejor" lugar podría no ser lo suficientemente grande como para caber en el archivo.

Si la aplicación le dice a NTFS el tamaño real del archivo (con SetEndOfFile ()), NTFS puede hacer un mejor trabajo al encontrar espacio contiguo para el archivo (la API SetEndOfFile hace que NTFS asigne almacenamiento para todo el archivo).

Tu problema debe ser con Opera. Acabo de ver un montón de archivos en una unidad muy llena y fragmentada. Los archivos grandes descargados con Chrome eran contiguos.

Esto sugiere que Chrome conocía el tamaño del archivo al comienzo de la descarga, por lo que le dijo a NTFS el tamaño del archivo que esperar. Si lo hace, NTFS intentará colocar el archivo en un solo fragmento, o cuando ningún fragmento sea lo suficientemente grande, en los fragmentos más grandes disponibles. Curiosamente, siempre usa estos fragmentos en orden descendente de tamaño, por lo que los archivos grandes copiados por Explorer en una unidad fragmentada pueden saltar por toda la unidad.

Cuando el programa no conoce el tamaño del archivo, o no se molesta en decirle a NTFS, sino que simplemente abre un archivo y comienza a escribir datos secuenciales, parece que NTFS actúa de manera muy similar a FAT32, que simplemente comienza en el primer clúster disponible (o la primera disponible después de la última asignada en esa sesión) luego usa lo que esté disponible de allí en adelante. Como ejemplo, aproximadamente al mismo tiempo le pedí a CCleaner que escaneara el registro, haciendo que lo respaldara en un gran archivo txt ".Reg". Este archivo comenzó cerca del inicio de la unidad y luego se dispersó en 127 fragmentos diferentes. A diferencia de los archivos copiados con Explorer o descargados con Chrome, en cada archivo que miré, los clústeres se asignaron en orden ascendente.

Para esta investigación utilicé Winhex (versión de prueba gratuita disponible en Winhex.com). Al mirar una entrada de directorio. haga clic con el botón derecho en un nombre de archivo y elija Posición, Lista de clústeres, para ver la lista de clústeres utilizados por ese archivo.