Compresión NTFS en SSD: altibajos

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

Por otro lado, dado que las SSD son mucho más rápidas que las HDD, esperaría que un mayor rendimiento resulte en un mayor uso de la CPU. ¿Puede esto convertirse en un problema? ¿Alguna otra idea 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, prefiero apagarlo:

Microsoft escribió esto hace un tiempo en un blog :

NTFS comprime los archivos dividiendo el flujo de datos en CU (esto es similar a cómo funcionan los archivos dispersos). Cuando se crean o cambian los contenidos de la secuencia, cada CU en la secuencia de datos se comprime individualmente. Si la compresión resulta en una reducción de uno o más grupos, la unidad comprimida se escribirá en el disco en su formato comprimido. Luego, se agrega un rango de VCN disperso al final del rango de VCN comprimido para fines de alineación (como se muestra en el ejemplo a continuación). Si los datos no se comprimen lo suficiente como para reducir el tamaño en un clúster, toda la CU se escribe en el disco en su forma no comprimida.

Este diseño hace que el acceso aleatorio sea muy rápido ya que solo una CU necesita descomprimirse para acceder a cualquier VCN en el archivo. Desafortunadamente, el acceso secuencial grande será relativamente más lento ya que se requiere la descompresión de muchas CU para realizar operaciones secuenciales (como copias de seguridad).

Y en un artículo de KB escribe esto :

Si bien la compresión del sistema de archivos NTFS puede ahorrar espacio en el disco, la compresión de datos puede afectar negativamente el rendimiento. La compresión NTFS tiene las siguientes características de rendimiento. Cuando copia o mueve un 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 copia o se mueve entre carpetas en la misma computadora. Los archivos comprimidos también se expanden antes de copiarlos en la red, por lo que la compresión NTFS no ahorra ancho de banda de la red.

Debido a que la compresión NTFS es intensiva en el procesador, el costo de rendimiento es más notable en los servidores, que con frecuencia están vinculados al procesador. Los servidores muy cargados 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 con servidores de solo lectura, de lectura mayoritaria o con poca carga.

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

Debido a que las carpetas de inicio de los usuarios y los perfiles móviles utilizan muchas operaciones de lectura y escritura, Microsoft recomienda que coloque las carpetas de inicio de los usuarios y los perfiles móviles en un volumen que no tenga compresión NTFS en la carpeta principal o en la raíz del volumen.

Resumen:

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

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

Para SSD, la compresión NTFS no debe usarse.

Ahora enumeraré algunos motivos para tal afirmación:

Motivo Nº1: matará SSD musch más rápido, ya que hace dos escrituras; La compresión NTFS siempre escribe datos sin comprimir antes de comenzar la compresión en la RAM y luego vuelve a escribir los datos comprimidos solo si es una ganancia de al menos 4KiB.

Motivo Nº2: el uso del clúster NTFS 4KiB en un SSD está perdiendo el 50% de la velocidad del SSD, verifique cualquier punto de referencia y verá que los bloques 128KiB hacen que el SSD sea dos veces más rápido que el uso de bloques 4KiB, y la compresión NTFS solo se puede usar en particiones NTFS del clúster 4KiB.

Motivo Nº3: hay contenedores (como PISMO File Mount) que pueden crear un contenedor que se ve como una compresión y / o cifrado sobre la marcha, tales contenedores hacen la compresión en la RAM y no envían datos sin comprimir al disco antes de volver a escribir en forma comprimida, también más, PISMO obtiene una mejor relación de compresión que NTFS.

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

El otro punto es VELOCIDAD, cualquier compresión se realiza en la CPU, por lo que si no tiene una CPU muy rápida (se usa monohebra para tal en NTFS mientras se usa multihilo en algunos contenedores) verá una lectura / escritura muy lenta cuando está comprimido; Lo peor es que puede tener una CPU muy rápida, pero si se usa para otras cosas (como renderizado, transcodificación, etc.) no queda CPU para la compresión, por lo que nuevamente obtendrá un bajo rendimiento.

La compresión NTFS solo es buena para los discos lentos tradicionales cuando 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 64 KB (comprimido o no) se escribe en un múltiplo de la posición de 64 KB; la única forma de empaquetar dichos fragmentos es después de la compresión (o escribir en una carpeta comprimida) hacer una desfragmentación de dicho archivo.

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

Nadie habla sobre el problema mayor en SSD no, es la fragmentación.

Cada bloque de 64 KB se escribe donde estaría sin compresión, pero se puede comprimir, por lo que al menos es <= 60 KB, luego escribe menos de 64 KB, el bloque de nido de bits irá a donde sería como si el anterior no estuviera comprimir, por lo que muchas brechas aparecen.

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

Y para los SSD hay algo que no se dice, ¿cómo diablos escribe? Quiero decir, si lo escribe sin comprimir y luego lo sobrescribe con la versión comprimida (por cada megabloque de 64 KB), la vida útil del SSD se reduce mucho; pero si lo escribe directamente en forma comprimida, entonces SSD live podría ser más corto o más corto ... más largo si escribe esos 64KiB solo a la vez, más corto, mucho más corto si escribe esos 64KiB en 4KiB, porque escribirá tales 64 KB (en forma comprimida) tantas veces como 64/4 = 16 veces.

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

Cuando hablo de CPU rápida o lenta, quiero decir en ese momento, la CPU puede ser utilizada por 'matemáticas' u otro proceso, por lo que siempre piense en la CPU libre, no en las especificaciones de la CPU en el papel, lo mismo ocurre con el disco / SSD, puede estar en uso por múltiples procesos.

Digamos que tiene 7Zip escribiendo un archivo enorme desde otro disco con LZMA2, usará mucha CPU, por lo que si al mismo tiempo está copiando un archivo comprimido NTFS, no tiene CPU libre, por lo que irá más lento que sin NTFS compresión, pero tan pronto como 7Zip termine de usar la CPU, dicha CPU podrá comprimir NTFS más rápido, 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 también permite la inscripción, tanto sobre la marcha como transparente para las aplicaciones), proporciona una relación de compresión mucho mejor y menos impacto en la CPU, mientras que es una lectura y escribir sobre la marcha, no es necesario descomprimir antes de usar, simplemente montarlo y usarlo en modo lectura y escritura.

Dado que PISMO realiza 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 datos al disco dos veces, primero sin comprimir, y después de eso, si puede comprimir, se superpone en forma comprimida. .

¿Por qué la velocidad de escritura comprimida NTFS en mi SSD es cercana a la mitad de la no comprimida con archivos que comprimir a cerca de la mitad de su tamaño o tamaños comprimidos inferiores? En mi AMD Threadripper 2950 (32 núcleos y 64 hilos) con 128GiB de ram (CPU rápida, CPU muy rápida) con menos del 1% de uso, por lo que hay suficiente CPU para hacer la compresión más rápido que la velocidad secuencial máxima de SSD, tal vez porque La compresión NTFS comienza después de que los bloques de 64 KB 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 el caché de Linux me informa que dichos clústeres 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 dado que después se sobrescriben con datos comprimidos, Linux no envía datos sin comprimir al disco,

Mi recomendación es que no use la compresión NTFS, excepto dentro de máquinas virtuales que ejecutan Windows si el host es Linux, y nunca si usa la CPU mucho o si su CPU no es lo suficientemente rápida.

El SSD moderno tiene una memoria caché interna enorme, por lo que el sistema de caché interno SSD puede mitigar la escritura + sobre escritura causada por la compresión NTFS.

Mis pruebas se realizaron en SSD "bonitas" sin RAM interna para caché dentro de la SSD, cuando las repito en las que tienen memoria caché de ram, la velocidad de escritura es más rápida, pero no como uno pensaría.

Haga sus propias pruebas y use archivos de gran tamaño (más grandes que el tam total instalado para evitar resultados ocultos en la memoria caché).

Por cierto, algo que algunas personas no saben sobre la vómitos NTFS ... cualquier archivo de 4KiB o inferior nunca tendrá una compresión NTFS porque no hay forma de reducir su tamaño al menos 4KiB.

NTFS copression toma un bloque de 64KiB, comprimirlos y si puede reducir un clúster (4KiB) entonces se escribe comprimido, 64KiB son 16 bloques de 4KiB (consecutivos).

Si un archivo de 8 KB cuando finaliza la compresión, el resultado final es superior a 4K KB, no puede guardar ningún clúster, por lo que se escribe sin comprimir ... y así sucesivamente ... la presión debe ganar al menos 4K KB.

Ah, y para la compresión NTFS, el NTFS debe tener un tamaño de clúster de 4KiB.

Pruebe y realice una prueba: use un clúster de 128 KB en un NTFS en SS. Verá una mejora en el rendimiento enorme en las velocidades de escritura y lectura.

Los sistemas de archivos en SSD con un clúster de 4KiB están perdiendo mucha velocidad, en la mayoría de los casos más de un 50% de pérdida ... vea cualquier punto de referencia que pruebe con diferentes tamaños de bloque, desde 512 Bytes hasta 2MiB, la mayoría de SSD escribe al doble velocidad cuando está en un tamaño de clúster de 64 KB (o 128 KB) que en 4K KB.

¿Quieres un verdadero impulso en tu SSD? No use el clúster 4KiB en el sistema de archivos, use 128KiB.

Solo use el clúster 4KiB si más del 99% de sus archivos tienen menos de 128KiB.

Etc, etc, etc ... prueba, prueba y prueba tu propio caso.

Nota: Cree la partición NTFS del sistema con la parte de disco en modo consola mientras instala Windows con un clúster de 128 KB o desde otro Windows, pero no permita que Windows formatee en la parte gráfica del instalador (siempre lo formateará como NTFS de clúster 4KiB).

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

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

Cuidado: Windows intenta comprimir NTFS algunos directorios internos, no importa si dice que no hay compresión NTFS, la única forma de evitarlo realmente es si el tamaño del clúster NFTS es diferente a 4KiB, ya que la compresión NTFS solo funciona en particiones NTFS de tamaño de clúster 4KiB

Veo los comentarios de otros, y creo que las personas a menudo olvidan el escenario más útil donde 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 solo 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 está en mi computadora portátil con 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 herramientas de desarrollo tienen propiedades similares: una tonelada de archivos de texto pequeños y altamente comprimibles (encabezados, código, archivos XML). Estoy comprimiendo Matlab ahora mismo antes de instalar Intel Quartus FPGA devtool, y Octave ya está comprimido de la siguiente manera:

1.55 GB Tamaño de datos en el disco: 839 GB Contiene 34.362 archivos 1.955 carpetas

Estas cosas se escriben una vez y se leen millones de veces durante las compilaciones del proyecto. Tiene mucho sentido gastar algo de energía de la CPU para descomprimirlo y ahorrar tal vez la mitad de su precioso espacio SSD.

Necesitas comparar dos veces para saber. Comprimido. Sin comprimir Olvídate del desgaste de los SSD. Necesita un ssd y una CPU rápidos para que no se produzca un cuello de botella.

Un SSD de 512 gb es de 50 dólares en estos días. El acceso de disco más rápido para mí hasta ahora es usar 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 12 GB de RAM instalados en mi computadora portátil. Linux mint carga y casi cero acceso al disco ocurre después. A menos que lo inicies. Windows simplemente tiene una manera de mantenerse ocupado sin tareas visibles.