¿Se fragmenta el registro de Windows?

La respuesta corta es que sí. La larga es que no mucho. Veamos.

Acabo de terminar de leer la parte del libro de Windows Internals que se refiere al registro de Windows, y básicamente me ha quedado un mal sabor de boca, cosa que a veces suele pasar con este tipo de libros políticamente aprobados, y es que no deja nada claro si el registro se fragmenta o no.

En disco, el registro no es más que una serie de ficheros repartidos a lo largo de varios lugares, ficheros que se corresponden con las diferentes ramas del mismo. La mayor ventaja de Vista y siguientes frente a XP es que ahora existe un juego de llamadas a función que realizarán operaciones transaccionales sobre el mismo. Es decir, igual que en las bases de datos –y el registro no deja de ser una-, iniciamos una transacción, realizamos una serie de acciones y si las completamos bien, cerramos dicha transacción, y si no, la abortamos. Para los programas instaladores esta característica es cojonuda, y a veces también para los programas de usuario. Con sólo imaginarnos dejar el registro a medio actualizar a causa de un corte de corriente…

Lo que sí queda claro es que en memoria la fragmentación es mínima. Es decir, casi da igual el grado de fragmentación que haya en los archivos (los hive, como los llaman), cuando estos son cargados a memoria mediante virtualización de la misma, la posible fragmentación queda reducida al mínimo. Además, los valores más comúnmente accedidos quedan cacheados. También se mantienen listas y cachés de escritura, para minimizar la sobrecarga en el sistema, lo que a veces, ante un corte imprevisto de corriente, hace que no se graben dichas modificaciones, aunque Windows garantiza la no corrupción de los hives mediante un sistema de mapeados y de escrituras en ficheros dobles y triples (más o menos lo mismo que hago yo con los firmwares cuando los datos no deben corromperse ante un corte de luz –en mi caso se trata de memorias flash y eeproms, pero la situación es la misma). La descarga a disco se hace cada cinco segundos, aunque podemos forzar nosotros una mediante la llamada a la función RegFlushKey() que, pese a lo que diga la documentación, hace un volcado de todo lo pendiente, no solo de la Key abierta.

Pero en disco la cosa no está tan clara, y los autores tampoco lo dicen expresamente, pero parece ser que sí, que el registro se puede fragmentar.

El registro se guarda en disco en bloques de 4KB. Es decir, aunque necesitemos 1 byte, el hive crecerá en 4KB. Eso no quiere decir que hayamos desperdiciado el resto, que no va a ocurrir, ya que luego dicho bloque se irá rellenando conforme se vayan añadiendo claves.

Ese es el primer nivel de indirección. Encima existe un nuevo nivel lógico, en el que el registro se distribuye en forma de listas sobre dichos bloques, y que realmente conforman la estructura que nosotros vemos. Digamos que este nivel consiste en una especie de mezcla de árbol y lista enlazada que se va distribuyendo a lo largo de los bloques en disco.

La combinación de ambas estructuras permite la fragmentación de forma muy fácil: tan solo hay que ir creando árboles y luego eliminando nodos y árboles anteriores. De hecho, en poco tiempo podríamos tener un buen nivel de fragmentación, sobre todo cuando hemos instalado y desinstalado un montón de programas.

No obstante, Windows lucha contra esta fragmentación mediante la compactación de los espacios libres. Es decir, cuando en un bloque físico hay huecos, estos serán compactados para dejar el mayor espacio libre contiguo, para –creo entender- volver a ser reutilizado.

No obstante, el bloque no será liberado de disco hasta que no esté completamente vacío, y sólo cuando esté al final del fichero. Es aquí donde puede venir la fragmentación, ya que podríamos tener muchos bloques vacíos por en medio y una jodida clave al final que nos impidiera la limpieza de un buen espacio en disco, ya que el algoritmo de desfragmentación no coloca los huecos al final, sino que simplemente los maximiza.

Y aquí es donde entra la estadística. Estadísticamente hablando, siempre habrá algo de fragmentación porque habrá huecos intermedios, que serán rellenados conforme se vayan necesitando, y en el peor de los casos el registro no decrecerá en tamaño, pero tampoco crecerá hasta que todos los huecos estén rellenos.

Lo que más me jode de todo esto es que en el libro no está muy claramente contado, sino que el tema de la fragmentación se recorre de puntillas, como si fuera un pecado. Tan sólo se comentan, de pasada, dos funciones que podrían permitirnos compactarlo y quizás decrecerlo: RegSaveKey() y RegReplaceKey(), que dice son usadas por Windows Backup.

Podríamos intentar jugar con dichas funciones para ver si conseguimos compactar nuestro registro pero, siéndoos sincero, no tengo ganas de trastear con algo que podría dejar mi ordenador completamente inservible sólo por ganar unos cuantos megas de disco…

9 comentarios en “¿Se fragmenta el registro de Windows?”

  1. Bueno realmente el tamaño del archivo de registro no lo considero lo suficientemente grande como para que la fragmentación tenga un impacto significativo.
    De hecho, al menos en mi experiencia personal, la fragmentación en disco con las velocidades de búsqueda actuales tampoco tiene mayor impacto en el uso que le da un usuario final, tal vez en servidores el tema sea diferente.

    saludos

  2. @Pacheco, creo que estás bastante equivocado; la diferencia es muy significativa. Haz cualquier cálculo con acceso a disco en uno fragmentado y luego compara tras defragmentar.

  3. Señor, gran artículo.

    Desfragmentar un disco duro de 1 TB llevará tiempo, no?

    Y una duda, por curiosidad, en C# cuál sería la mejor forma de hacer “una transacción” para actualizar una base de datos y modificar (o mover, copiar, crear) un fichero ??

    Es decir, que las operaciones de actualizar base de datos y acceso a disco fuesen ´como una sóla operación atómica. Nunca vi ningún ejemplo sobre este tema.

    Saludos y gracias.

  4. Hola, feliz año a todos!

    Preguntoncojonero a mí se me ocurre que la forma más sencilla es implementando un control de excepciones try..catch para que si ocurre cualquier cosa “inesperada”, eches para atrás todo. Que según lo que sea puede ser pesado borrar todo lo parcialmente hecho (si en el bloque try mantienes un “contador” de operaciones, te lo puede facilitar), pero en mi aún corto entender de las tripas de Windows y .NET, creo que no hay manera de hacerle un ‘rollback’ a las operaciones sobre el registro.

  5. Pablo, Preguntacojonero creo que está preguntando sobre bases de datos, no sobre el registro. Supongo que SQL tendrá alguna forma de realizar transacciones y roll-back, pero no es mi tema y no tengo ni idea.

    Respecto al registro, a partir de Vista hay varias funciones nuevas que permiten las transacciones, la que la inicia, la cierra y la aborta, y las de escritura en el propio registro. Lo que no sé es si han sido mapeadas a .NET o no. Quizás lo estén en el 3.5 o vayan a estarlo en el 4.0…

  6. el registro cuanto ocupa?? creo que muy poco, como para que haya un pérdida de rendimiento notable por la desfragemtnacion.

    Otra cosa es tener un disco duro de 1 Tera lleno de vídeo de 4 GB y muy desfragemntado. Pero eso pasa en cualquier SO.

    Aquí se habla de la fragmetancion del registro.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *