verifique independientemente que TRIM realmente funcione en SSD

Tengo una LUKSpartición con la /dev/sda1que luksOpen with --allow-discards:

cryptsetup --allow-discards luksOpen /dev/sda1 root

Luego monte el ext4sistema de archivos con la discardopción:

grep /dev/mapper/root /proc/mounts
/dev/mapper/root / ext4 ro,relatime,block_validity,discard,delalloc,barrier,user_xattr,acl 0 0

Luego recorto espacio libre en la partición montada:

fstrim -v /

con df, veo que /tiene 80% de espacio libre. Eso significa que el /dev/sda180% del disco son ceros binarios.

Si clono la imagen con cat

cat /dev/sda1 > sda1.img

y comprimir la imagen con xz, esperaría que se comprimen todos los ceros en el disco. Como el 20% de los datos en el disco está encriptado, debe parecer aleatorio y no comprimible. Por lo tanto, la imagen comprimida xz debe ser de aprox. 20% del tamaño bruto.

Sin embargo, la imagen comprimida xz resultante tiene aproximadamente el mismo tamaño que el original sin procesar.

¿Es correcto mi razonamiento?

¿Por qué mi teoría no se traduce en práctica?

Tu lógica no es incorrecta. Pero solo es válido si se cumplen algunas condiciones.

El comando TRIM , como se especifica en el conjunto de comandos ATA , puede o no poner a cero los sectores contra los que se emite.
En realidad, el estándar se centra en qué datos deben devolverse después de que se haya emitido TRIM ¹ :

Este estándar especifica los siguientes comportamientos para los sectores que el dispositivo recorta (ver 7.5.3.3):

a) no determinista: los datos en respuesta a una lectura de un sector recortado pueden cambiar para cada lectura hasta que el host escriba el sector;
b) Lectura determinista después del recorte (DRAT): los datos devueltos en respuesta a una lectura de un sector recortado no cambian, pero pueden ser diferentes a los datos que se devolvieron previamente; y
c) Leer ceros después del recorte (RZAT): los datos devueltos en respuesta a una lectura del sector recortado son cero.

[...] Tanto para dispositivos de almacenamiento DRAT como no deterministas, los datos devueltos en respuesta a un comando de lectura a un LBA que se ha recortado correctamente:

a) pueden ser los datos devueltos previamente para el LBA especificado;
b) puede ser un patrón generado por el dispositivo de almacenamiento; y
c) no son datos previamente escritos en un LBA diferente por el host.

Por lo tanto, lo que devuelve su dispositivo fstrimdepende de las características que implementa. A menos que sea compatible con RZAT, la suposición de que los datos leídos desde un dispositivo recortado serán solo ceros no es válida.

Puede usar hdparmpara verificar esto:

sudo hdparm -I /dev/sdX | grep -i trim

Realicé algunas pruebas usando dos SSD sday sdb. Mismo fabricante, diferentes modelos, con diferente conformidad ATA:

$ sudo hdparm -i /dev/sdb
 ...
 Drive conforms to: Unspecified:  ATA/ATAPI-3,4,5,6,7
 ...

$ sudo hdparm -i /dev/sda
 ...
 Drive conforms to: unknown:  ATA/ATAPI-2,3,4,5,6,7
 ...

Los dos SSD tienen soporte diferente para TRIM:

$ sudo hdparm -I /dev/sda | grep -i trim
           *    Data Set Management TRIM supported (limit 1 block)

$ sudo hdparm -I /dev/sdb | grep -i trim
           *    Data Set Management TRIM supported (limit 8 blocks)
           *    Deterministic read ZEROs after TRIM

Puedo confirmar que, después de emitir fstrim, la unidad que admite "CERO de lectura determinista después de TRIM" (RZAT) parece haber puesto a cero la partición en cuestión casi por completo. Por el contrario, la otra unidad parece haber puesto a cero (o de lo contrario reemplazado por algún patrón altamente compresible) solo una parte menor del espacio liberado.

¹ _{Fuente en línea: INCITS 529: Tecnología de la información - Conjunto de comandos ATA / ATAPI - 4 (ACS-4)}

Nota sobre las pruebas:

Como señaló frostschutz en los comentarios, una lectura posterior fstrimpuede devolver datos del caché del sistema operativo y no del dispositivo recortado. Es, por ejemplo, lo que sucedió en esta pregunta .
(También señalaría esta respuesta a la misma pregunta para un método alternativo para probar TRIM).

Entre fstrimy una lectura posterior, es posible que deba soltar el caché, por ejemplo, con:

echo 3 | sudo tee /proc/sys/vm/drop_caches

Dependiendo del tamaño de la partición con la que está jugando, no soltar el caché puede ser suficiente para que sus pruebas fallen.

Nota sobre su configuración:

La discardopción de montaje habilita el ajuste continuo, es decir, cada vez que se eliminan los archivos. No es requerido por fstrim. De hecho, TRIM a pedido y TRIM continuo son dos formas distintas de gestionar las operaciones TRIM. Para obtener más información, quisiera señalar la unidad de estado sólido en Arch Linux Wiki, que tiene una cobertura detallada de este asunto.

¿El SSD tiene una capa de cifrado de hardware incorporada? Si tiene uno, entonces los bloques TRIMmed pueden ser todos ceros (o posiblemente todos) en el nivel de hardware en bruto, pero dado que la computadora los ve a través de la capa de cifrado, aparecerán como galimatías pseudoaleatoria después de pasar todo -Ceroes bloque sin procesar a través del proceso de descifrado.

Tal capa de cifrado de hardware tendría algunas ventajas:

• Permitiría una funcionalidad de borrado de seguridad muy rápida: solo haga que la unidad destruya la clave original utilizada en la capa de cifrado de hardware y la reemplace por una nueva y todos los datos serán instantáneamente irrecuperables para la mayoría de los propósitos prácticos.
• Como todos los datos que alcanzan el nivel de hardware sin procesar se cifrarían, se garantizaría que se vería pseudoaleatorio y, por lo tanto, sería en gran medida homogéneo. Esto podría ayudar a evitar puntos fríos / calientes y simplificar mucho la estimación del desgaste.

Descartar no es lo mismo que Cero.

Si desea poner a cero con cryptsetup, puede reducir fs, luego el bloque de cripta y luego dd el espacio de volumen no utilizado.

Si desea saber si el ajuste funcionó, hacer una prueba de velocidad debería ser un indicador después de un uso intensivo.

https://linux.die.net/man/8/fstrim https://en.m.wikipedia.org/wiki/Trim_(computing)

df informar espacio libre no implica espacio cero.

trimle dice al dispositivo de almacenamiento que los bloques no se usan. No creo que esto los ponga a cero.