En este articulo vamos a ver las razones para no usar Partition Magic o similares

La MFT ocupa (reserva) el 12,5% del espacio en disco durante el formateo. Efectivamente, puede crecer y puede estar fragmentada, pero lo más grave, es que aunque crezca, en principio no decrece. El PM, al disminuir una partición deja la MFT como estaba.

Esto, no se por qué motivo no le gusta a Windows ya que lo que sí se nota es que el rendimiento del disco decrece significativamente.

Hay unas pruebas que siempre aconsejo: crearnos por ejemplo 80.000 archivos y ver el tiempo de creación, en un disco recién particionado con herramientas de Windows. En ese mismo, cuando le hacemos disminuir a la mitad con el PM, y otra prueba aumentándole con el PM al doble del original.

Un simple línea de comandos, puede hacernos crear esos 80.000 archivos (pequeñitos), por ejemplo:for /L %i in (1,1,80000) do echo texto del archivo > n%i.txt medimos los tiempos de creación (esto está probado con discos rápidos de ultima generación), y los tiempos aumentan 10 a uno al disminuir la partición a la mitad, y aumentan 3 a 1 al aumentar la partición al doble. Vuelven los tiempos originales al dejar la partición como estaba.

Por tanto, algo queda descompensado en ese disco.

Pero el peligro más gordo del PM, es que no maneja bien el MBR para indicar los comienzos finales de particiones, o al menos no los maneja bien en muchos casos (entiendo que es debido al tipo de controladora de disco).

PM, puedes buscar en Google, es caso de miles de desastres, bien en el momento de la conversión, o lo más peligroso, poco después cuando manejamos otra partición con el gestor de Windows (por ejemplo).

Mi experiencia me indica que en controladoras viejas y muy extendidas, no suele dar problemas, ahora bien, en las nuevas, o desconocidas para él… adiós el disco.

Es más fiable, infinitamente más , en este sentido el Acronis Partition Expert (www.acronis.com) pero aun así, los tiempos de ejecución anteriores siguen siendo los mismos: es decir, algo no rula.

Como resumen:

* Por los problemas dados, yo nunca lo aconsejo a un usuario final. A un técnico con responsabilidad, bueno, el sabrá (y se supone que tiene copia de seguridad).

* Pero a un vicioso de las prestaciones, rendimientos y tiempos de ejecución (como yo) no se lo aconsejo.

Y otra cosa que se me olvidaba la prueba del: for /L %i in (1,1,80000) do echo texto del archivo > n%i.txt es una prueba cabrona y podríamos decir que tendenciosa realizada a propósito para incordiar a la MFT, ya que los archivos de menos de novecientos y pico bytes se almacena completos en la MFT y no en la estructura del disco.

La prueba anterior se completa con otra similar en la cual forzamos a grabar realmente en el disco.

Para ello nos creamos un simple archivo de texto de más de 1 KB. Por ejemplo cualquier archivo entre 4 KB y 8 KB, y lo llamamos prueba.dat.

Ahora modificamos la línea anterior: for /L %i in (1,1,80000) do copy prueba.dat n%i.txt esto evidentemente tardará más . Pero aquí la diferencia de tiempos es todavía más escandalosa!

Merece la pena probarlo, nos sorprenderemos .

José Manuel Tella Llop