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.