22 votos

Compresión NTFS en SSD: ventajas y desventajas

Este tema habla de la compresión NTFS en los discos duros como método para mejorar el rendimiento de acceso al disco, y concluye que la mayoría de las veces es deficiente. Pero yo siempre he visto la compresión como una forma de conservar el espacio, y he aprendido su eficacia en eso. Y ahora tengo un SSD donde el espacio es caro y la penalización del rendimiento, por ejemplo, por leer/escribir 2 clusters en lugar de 1, es mucho menor.

Por otro lado, dado que los SSD son mucho más rápidos que los HDD, es de esperar que un mayor rendimiento se traduzca en un mayor uso de la CPU. ¿Puede esto convertirse en un problema? ¿Alguna otra opinión al respecto?

Me gusta el efecto de ahorro de espacio, no es enorme pero está ahí. Sin embargo, si el rendimiento es una preocupación, preferiría desactivarlo:

enter image description here

18voto

magicandre1981 Puntos 35650

Microsoft escribió esto hace un tiempo en un blog :

NTFS comprime los archivos dividiendo el flujo de datos en CU's (esto es similar a cómo funcionan los archivos dispersos). Cuando el contenido del flujo se se crea o cambia, cada CU del flujo de datos se comprime individualmente. Si la compresión resulta en una reducción de uno o más más clusters, la unidad comprimida se escribirá en el disco en su formato comprimido. A continuación, se añade un rango VCN disperso al final del del rango VCN comprimido con fines de alineación (como se muestra en el ejemplo siguiente). Si los datos no se comprimen lo suficiente como para reducir el tamaño en un clúster, entonces toda la CU se escribe en el disco en su sin comprimir.

Este diseño hace que el acceso aleatorio sea muy rápido, ya que sólo es necesario descomprimir una UC para acceder a cualquier VCN del archivo. Desafortunadamente, los accesos secuenciales grandes serán relativamente más lentos, ya que descompresión de muchas CU para realizar operaciones secuenciales (como las copias de seguridad).

Y en un El artículo de KB escribe lo siguiente :

Aunque la compresión del sistema de archivos NTFS puede ahorrar espacio en el disco, comprimir datos puede afectar negativamente al rendimiento. La compresión NTFS tiene la función siguientes características de rendimiento. Al copiar o mover un archivo archivo NTFS comprimido a una carpeta diferente, NTFS descomprime el archivo, copia o mueve el archivo a la nueva ubicación y luego vuelve a comprimir el archivo. Este comportamiento se produce incluso cuando el archivo se copiado o movido entre carpetas en el mismo ordenador. Los archivos comprimidos también se expanden antes de copiarse en la red, por lo que la compresión NTFS no ahorra ancho de banda en la red.

Porque la compresión NTFS es de procesador, el coste de rendimiento se nota más en los servidores, que a menudo se ven obligados a usar el procesador. Los servidores muy cargados y con mucho tráfico de escritura son malos candidatos para la compresión de datos. Sin embargo, es posible que no experimente una degradación significativa del rendimiento degradación del rendimiento con servidores de sólo lectura, de lectura mayoritaria o con poca carga. de lectura o con poca carga.

Si ejecuta un programa que utiliza el registro de transacciones y que constantemente escribe en una base de datos o en un registro, configure el programa para que almacene sus archivos en un volumen que no esté comprimido. Si un programa modifica los datos a través de secciones mapeadas en un archivo comprimido, el programa puede producir páginas "sucias" sucias" más rápido de lo que el escritor mapeado puede escribirlas. Programas como Microsoft Message Queuing (también conocido como MSMQ) no funcionan con la compresión NTFS debido a este problema.

Dado que las carpetas de usuario y los perfiles itinerantes utilizan muchas operaciones de lectura y operaciones de lectura y escritura, Microsoft recomienda que coloque las carpetas de inicio del usuario y los perfiles itinerantes en un volumen que no tenga compresión NTFS en la carpeta principal o en root del volumen.


Resumen:

sólo comprimir archivos pequeños que nunca cambian (sólo lecturas y no escrituras en ellos) porque las lecturas son rápidas, pero las escrituras requieren descompresión y nueva compresión, lo que requiere potencia de la CPU y el tipo de almacenamiento no es tan importante.

7voto

Laura Puntos 79

Como Claudio dice muchas cosas en detalle, voy a retomar su opinión que también es la mía, he visto los mismos efectos después de probar lo que él dice.

En el caso de las SSD no se debe utilizar la compresión NTFS.

Ahora enumeraré algunos motivos para tal afirmación:

Motivo Nº1: Acabará con el músculo del SSD más rápido, ya que hace dos escrituras; la compresión NTFS siempre escribe los datos sin comprimir antes de iniciar la compresión en la RAM y luego reescribe los datos comprimidos sólo si hay una ganancia de al menos 4KiB.

Motivo Nº2: Usar un cluster NTFS de 4KiB en un SSD es perder el 50% de la velocidad del SSD, comprueba cualquier benchmark y verás que los bloques de 128KiB hacen que el SSD sea dos veces más rápido que usando bloques de 4KiB, y la compresión NTFS sólo se puede usar en particiones NTFS de cluster de 4KiB.

Motivo Nº3: Existen contenedores (como PISMO File Mount) que pueden crear un contenedor que se ve como una compresión y/o encriptación al vuelo, dichos conteiners hacen la compresión en la RAM y no envían los datos sin comprimir al disco antes de reescribirlos en forma comprimida, además, PISMO consigue un mejor ratio de compresión que NTFS.

Hay muchos más motivos, pero estos son los más importantes.

El otro punto es la VELOCIDAD, cualquier compresión se hace en la CPU, por lo que si no tienes una CPU muy rápida (se usa un mono-hilo en NTFS mientras que se usa multi-hilo en algunos contenedores) verás una lectura/escritura muy lenta cuando se comprime; peor aún, puedes tener una cpu muy rápida, pero si está en uso para otras cosas (como renderizado, transcodificación, etc) no queda cpu para la compresión, por lo que de nuevo obtendrás un pobre rendimiento.

La compresión NTFS sólo es buena para discos lentos tradicionales cuando se tiene una cpu sin mucho uso, pero requiere una buena desfragmentación después de cada escritura (a nivel de archivo), porque cada bloque de 64KiB (comprimido o no) se escribe en una posición múltiple de 64KiB; la única forma de empaquetar esos fragmentos es después de la compresión (o de la escritura en una carpeta comprimida) hacer una desfragmentación de dicho archivo.

P.D.: Cuidado que estamos hablando de Windows en hardware real, no dentro de máquinas virtuales, lo importante es quien escribe en el medio físico, otros pueden tener capas de caché que pueden mitigar los efectos y también mejorar mucho las cosas.

7voto

xmp125a Puntos 143

Veo los comentarios de otros, y creo que la gente suele olvidar el escenario más útil en el que la compresión de archivos/carpetas NTFS tiene una gran ventaja en SSD: las herramientas de desarrollo modernas. Mi Matlab con licencia universitaria tiene en su carpeta de instalación (para el usuario ordinario, de sólo lectura) las siguientes cantidades de datos:

28,5 GB Datos 30,6 GB Tamaño en disco Contiene 729.246 archivos y 15.000 carpetas (!!!)

Esto es en mi portátil con un SSD de 500 GB, donde la partición de Windows es de 200 GB.

Sé que Matlab es un poco extremo en este sentido, pero muchas devtools tienen propiedades similares: una tonelada de pequeños archivos de texto altamente comprimibles (cabeceras, código, archivos XML). Ahora mismo estoy comprimiendo Matlab antes de instalar Intel Quartus FPGA devtool, y Octava ya está comprimido de la siguiente manera:

1,55 GB de datos Tamaño en disco 839 GB Contiene 34.362 archivos 1.955 carpetas

Estas cosas se escriben una vez y se leen millones de veces durante la construcción del proyecto. Tiene mucho sentido gastar algunos Potencia de la CPU para descomprimirlo y ahorrar quizás la mitad de su precioso espacio en el SSD.

5voto

Claudio Puntos 31

Nadie habla del problema mayor en los no SSD, es la fragmentación.

Cada bloque de 64KiB se escribe donde estaría sin compresión, pero se puede comprimir, por lo que al menos es <=60KiB, entonces se escribe menos de 64KiB, el bloque del nido de bits irá donde iría como si el anterior no estuviera comprimido, por lo que un montón de huecos apèars.

Pruébalo con un archivo de varios gigas de una máquina virtusl de cualquier sistema Windows (suelen reducirse al 50%, pero con un enorme >10000 fragmentos).

Y en el caso de los SSD hay algo que no se cuenta, ¿cómo demonios se escribe? Es decir, si lo escribe sin comprimir y luego lo sobrescribe con la versión comprimida (por cada megabloque de 64KiB), la vida del SSD se recorta mucho; pero si lo escribe directamente en forma comprimida, entonces la vida del SSD podría ser lo ger o más corta.... más larga si escribe esos 64KiB de una sola vez, más corta, mu h más corta si escribe esos 64KiB en 4KiB, porque escribirá esos 64KiB (en forma comprimida) tantas veces como 64/4=16 veces.

La penalización de rendimiento se debe a que el tiempo de la CPU necesario para comprimir/descomprimir es mayor que el tiempo ganado al no tener que escribir bloques de 4KiB... así que con una CPU muy rápida y un disco muy lento la compresión reduce el tiempo de escritura y lectura, pero si el SSD es muy rápido y la CPU es bastante lenta, escribirá mucho más lento.

Cuando hablo de CPU rápida o lenta me refiero a que en ese momento, la CPU puede estar en uso por 'matemáticas' u otro proceso, así que siempre piensa en la cpu libre, no en las especificaciones de la CPU en papel, lo mismo ocurre con el disco/SSD, puede estar en uso por múltiples procesos.

Digamos que tienes a 7Zip escribiendo un archivo enorme desde otro disco con LZMA2, utilizará mucha CPU, por lo que si al mismo tiempo estás copiando un archivo comprimido con NTFS, no tiene CPU libre, por lo que irá más lento que sin la compresión NTFS, pero en cuanto 7Zip termine de utilizar la CPU, dicha CPU podrá comprimir más rápido a NTFS, y en ese momento la compresión NTFS puede hacer las cosas más rápido.

Personalmente nunca uso la compresión NTFS, prefiero los contenedores PFO de montaje de archivos PISMO (con compresión, y además permite la encriptación, tanto al vuelo como transparente para las apps), da mucho mejor ratio de compresión y menos impacto en la CPU, a la vez que es una lectura y escritura al vuelo, no hace falta descomprimir antes de usar, sólo montar y usar en modo lectura y escritura.

Dado que PISMO hace la compresión en la RAM antes de escribir en el disco, puede hacer que el SSD dure más tiempo, mis pruebas de compresión NTFS me hacen pensar que envía los datos al disco dos veces, primero sin comprimir, y después si puede comprimir se sobreescribe en forma comprimida.

¿Por qué la velocidad de escritura comprimida de NTFS en mi SSD es casi la mitad de la no comprimida con archivos que se comprimen a casi la mitad de su tamaño o a tamaños comprimidos inferiores? En mi AMD Threadripper 2950 (32 núcleos y 64 hilos) con 128GiB de ram (CPU rápida, muy rápida) a menos del 1% de uso de la misma, por lo que hay mucha CPU para hacer la compresión más rápido que la velocidad máxima secuential del SSD, tal vez porque la compresión NTFS comienza después de que los bloques de 64KiB se envían al disco sin comprimir y luego se sobrescriben con la versión comprimida ... Oh, si lo hago en una máquina virtual que ejecuta Linux en el host y Windows en el invitado, entonces la caché de Linux me informa de que esos clusters se escriben dos veces, y la velocidad es mucho, mucho más rápida (Linux está almacenando en caché las escrituras NTFS no comprimidas enviadas por el invitado de Windows y como después se sobrescriben con datos comprimidos, linux no envía datos sin comprimir al disco, ¡¡¡la caché de escritura de Linux!!!).

Mi recomendación es que no utilices la compresión NTFS, excepto dentro de máquinas virtuales huéspedes que ejecuten Windows si el host es Linux, y nunca si utilizas mucho la CPU o si tu CPU no es lo suficientemente rápida.

Los SSD modernos tienen un enorme caché interno de ram, por lo que la escritura+sobrecarga causada por la compresión NTFS puede ser mitigada por el sistema de caché interno del SSD.

Mis pruebas fueron hechas en SSD's "bonitos" sin RAM interna para caché dentro del SSD, cuando las repito en los que tienen caché de ram, la velocidad de escritura es rápida, pero no como uno pensaría.

Haz tus propias pruebas, y utiliza archivos de gran tamaño (mayores que el total de tam instalados para evitar resultados ocultos en la caché).

Por cierto, algo que algunas personas no saben sobre la vompresión de NTFS... cualquier archivo de 4KiB o menos nunca se comprimirá en NTFS porque no hay manera de reducir su tamaño al menos 4KiB.

La co presión de NTFS toma bloques de 64KiB, los comprime y si puede reducir un grupo (4KiB) entonces se escribe comprimido, 64KiB son 16 bloques de 4KiB (consecutivos).

Si un archivo de 8KiB al terminar la compresión el resultado final es de más de 4KiB no se guarda ningún cluster, por lo que se escribe sin comprimir,... y así sucesivamente... la compresión debe ganar al menos 4KiB.

Ah, y para la compresión NTFS, el NTFS debe ser con tamaño de cluster de 4KiB.

Intenta hacer una prueba: Utiliza un clúster de 128KiB en un NTFS en un SSD, verás una gran mejora en el rendimiento de las velocidades de escritura y lectura.

Los sistemas de archivos en SSD con clústeres de 4KiB pierden mucha velocidad, en la mayoría de los casos más de un 50% de pérdida... vea cualquier benchmark por ahí que pruebe con diferentes tamaños de bloque, desde 512Bytes hasta 2MiB, la mayoría de los SSD escriben al doble de velocidad cuando tienen un tamaño de clúster de 64KiB (o 128KiB) que con 4KiB.

¿Quieres un impacto real en tu SSD? No uses un cluster de 4KiB en el sistema de archivos, usa 128KiB.

Sólo utilice el clúster de 4KiB si más del 99% de sus archivos son menores de 128KiB.

Etc, etc, etc... pruebe, pruebe y pruebe su propio caso.

Nota: Cree la partición NTFS del sistema con diskpart en modo consola mientras instala Windows con cluster de 128KiB, o desde otro Windows, pero no deje que Windows formatee mientras está en la parte gráfica del instalador (siempre lo formateará como cluster NTFS de 4KiB).

Todos mis Windows están ahora instalados en una partición NTFS de 128KiB en un SSD de >400GiB (SLC).

Espero que las cosas se aclaren, M$ no dice cómo escribe NTFS comprimido, mis pruebas me dicen que escribe dos veces (64KiB sin comprimir, luego <=60KiB comprimidos), no sólo una vez (cuidado con eso si en SSD).

Cuidado: Windows intenta comprimir con NTFS algunos directorios internos, sin importar si dices que no se comprima con NTFS, la única forma de evitarlo es tener un tamaño de cluster NFTS diferente a 4KiB, ya que la compresión NTFS sólo funciona en particiones NTFS de 4KiB.

-3voto

Para saberlo, hay que hacer dos evaluaciones comparativas. Comprimido. Sin comprimir. Olvídate del desgaste de los SSD. Necesitas un ssd rápido y una CPU para que no se produzca ningún cuello de botella.

Un SSD de 512gb cuesta 50 dólares hoy en día. El acceso al disco más rápido para mí hasta ahora es el uso de Linux cuando sea posible y el mecanismo de cola de disco LIFO. En lugar de CFQ.

Windows 10 crea una actividad de disco infinita con 12GB de ram instalado en mi portátil. Linux menta carga y casi cero acceso al disco se produce después. A menos que lo inicie. Windows sólo tiene una manera de mantenerse ocupado sin tareas visibles.

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by:

X