fstrim recorta más de la mitad del tamaño de la partición aunque la partición esté montada con descarte

Cuando instalé mi SSD, simplemente monté discardy no me cansé. Sin embargo, hoy estaba leyendo sobre los pros y los contras de usar en su fstrimlugar y decidí ejecutar el programa para tener una idea de cuánto tiempo tomaría realmente (aún con mis particiones montadas con discard). El comando tomó varios minutos tanto en mi partición raíz como en mi partición. Para la partición de mi casa usé -vy obtuve esto:

$ sudo fstrim -v /home
/home: 137494052864 bytes were trimmed

¡Esto es más que la cantidad de espacio libre en la partición!

$ df -h /home
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2       206G   78G  118G  40% /home

Las ejecuciones posteriores terminan en menos de un segundo, por ejemplo:

$ sudo fstrim -v /home
/home: 0 bytes were trimmed

Seguramente, si siempre he montado la partición discard, fstrim¿no debería recortar una gran cantidad de datos como esa? La discardopción está definitivamente habilitada, aquí están las fstablíneas relevantes :

UUID=xxxxxxxx...    /          ext4   noatime,discard,errors=remount-ro  0      1
UUID=xxxxxxxx...    /home      ext4   noatime,discard,errors=remount-ro  0      2

Y mountlíneas de salida:

/dev/disk/by-uuid/xxxxxxxx... on / type ext4 (rw,noatime,discard,errors=remount-ro,stripe=128,data=ordered)
/dev/sda2 on /home type ext4 (rw,noatime,discard,errors=remount-ro,stripe=128,data=ordered)

El SSD es un TOSHIBA THNSNS256GMCP. ¿Por qué pasó esto?

— Graeme
fuente

Dos cosas aquí:

fstrimrecorta todos los datos que no están asignados en el sistema de archivos (bueno, en realidad no todos los datos, solo los bloques de datos que no están asignados, no creo que las partes no utilizadas de la tabla de inodo o las partes de bloques no completamente utilizados sean recortado), independientemente de si discardestá en uso o no. fstrimno puede saber cuál de esos bloques no asignados se ha "recortado" o no ya en el pasado, pero (en realidad el núcleo, todo el fstrimtrabajo se realiza en el FITRIM ioctl) no obstante, realiza un seguimiento de qué grupo de bloques se han recortado y no se recortarán nuevamente si no ha habido ninguna asignación en ese grupo de bloques desde entonces, a menos que esté solicitando un FITRIM con una longitud de extensión mínima menor (al verificar el código ext4, puede ser diferente para otros sistemas de archivos) que explica por qué obtiene 0 en la próxima ejecución.

Tenga en cuenta que no hace daño recortar un bloque que ya se ha recortado. Eso solo le dice al SSD nuevamente que puede hacer lo que quiera con él (como borrarlo para que pueda estar listo para usar de nuevo para otra cosa).
En la dfsalida, el valor "disponible" no tiene en cuenta el espacio para el que está "reservado" root, notará que 206 - 76 es 130G, no 118G. 12G (alrededor del 5%) están reservados. Vea tunefs -mpara cambiar cuánto está reservado.

— Stéphane Chazelas
fuente

Entonces, si fstrimno sabe lo que ya se ha recortado, ¿por qué informa 0 bytes la segunda vez? Seguramente esto debe provenir del disco, pero ¿por qué informaría un recorte tan grande la primera vez? Sin duda, el disco sería agnóstico sobre si discardo trimhabía sido utilizado.

— Graeme

@Graeme, argh, buen punto. fstrim, usa el ioctl FITRIM, y es el núcleo el que hace todo el trabajo e informa el resultado a fstrim. Supongo que el kernel realiza un seguimiento de lo que ya se ha recortado, pero solo puede hacer eso desde que se inició. Investigará y actualizará la respuesta.

— Stéphane Chazelas

Ok, sí, el núcleo debe rastrear lo que se ha recortado desde el arranque. Si reinicio y hago otra fstrim, obtengo aproximadamente la misma salida.

— Graeme

@Graeme, mira mi edición.

— Stéphane Chazelas

fstrimsolo emite lo apropiado ioctl, todo lo demás es decisión del sistema de archivos, y los sistemas de archivos se comportan de manera muy diferente. ext4intenta evitar recortar las mismas cosas una y otra vez, xfsno le importa y recorta todo lo que es gratis, otros pueden hacer otras cosas, incluso si lo admiten ... si es impredecible, quejarse ante el sistema de archivos.

— frostschutz