fstrim coupe plus de la moitié de la taille de la partition même si la partition est montée avec discard

Lorsque j'ai installé mon SSD, je l'ai simplement monté discardet je ne l' ai pas transpiré. Cependant, aujourd'hui, je lisais les avantages et les inconvénients de l'utilisation à la fstrimplace et j'ai décidé d'exécuter le programme pour avoir une idée du temps qu'il faudrait réellement (toujours avec mes partitions montées avec discard). La commande a pris plusieurs minutes sur mes partitions racine et domestique. Pour ma partition domestique, j'ai utilisé -vet obtenu ceci:

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

C'est plus que la quantité d'espace libre sur la partition!

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

Les manches suivantes se terminent en moins d'une seconde, par exemple:

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

Certes, si j'ai toujours eu la partition montée avec discard, fstrimne devrait pas couper une grande quantité de données comme ça? L' discardoption est définitivement activée, voici les fstablignes pertinentes :

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

Et mountlignes de sortie:

/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)

Le SSD est un TOSHIBA THNSNS256GMCP. Pourquoi cela arrive-t-il?

Deux choses ici:

1. fstrimcoupe toutes les données qui ne sont pas allouées dans le système de fichiers (enfin, pas vraiment toutes les données, seulement les blocs de données qui ne sont pas alloués, je ne pense pas que les parties inutilisées de la table d'inode ou les parties de blocs pas complètement utilisés sont coupé), qu'il soit discardutilisé ou non. fstrimne peut pas savoir lequel de ces blocs non alloués a été "coupé" ou pas déjà dans le passé, mais il (en fait le noyau, tout le fstrimtravail est fait dans le FITRIM ioctl) garde cependant le groupe de blocs ont été coupés et ne les coupera plus s'il n'y a pas eu de désallocation dans ce groupe de blocs depuis lors, à moins que vous ne demandiez un FITRIM avec une longueur d'extension minimale plus petite (en vérifiant le code ext4, cela peut être différent pour les autres systèmes de fichiers), ce qui explique pourquoi vous obtenez 0 lors de la prochaine exécution.

   Notez que cela ne nuit pas de couper un bloc qui a déjà été coupé. Cela revient à dire au SSD qu'il peut faire ce qu'il veut avec lui (comme l'effacer pour qu'il soit prêt à être utilisé à nouveau pour autre chose).

2. En dfsortie, la valeur "disponible" ne prend pas en compte l'espace "réservé" root, vous remarquerez que 206 - 76 est 130G, pas 118G. 12G (environ 5%) sont réservés. Voir tunefs -mpour changer le montant réservé.