Votre logique n'est pas incorrecte. Mais il n'est valable que si certaines conditions sont remplies.
La commande TRIM , comme spécifié dans le jeu de commandes ATA , peut ou non mettre à zéro les secteurs pour lesquels elle est émise.
En fait, la norme se concentre sur les données à retourner après la publication de TRIM 1 :
Les comportements suivants sont spécifiés par cette norme pour les secteurs que l'appareil coupe (voir 7.5.3.3):
a) non déterministe - les données en réponse à une lecture d'un secteur coupé peuvent changer pour chaque lecture jusqu'à ce que le secteur soit écrit par l'hôte;
b) Lecture déterministe après découpage (DRAT) - les données renvoyées en réponse à la lecture d'un secteur découpé ne changent pas, mais peuvent être différentes de celles qui ont été précédemment renvoyées; et
c) Lire les zéros après ajustement (RZAT) - les données renvoyées en réponse à une lecture du secteur ajusté sont nulles.
[...] Pour les périphériques de stockage DRAT et non déterministes, les données renvoyées en réponse à une commande de lecture à un LBA qui a été correctement coupé:
a) peut être les données précédemment renvoyées pour le LBA spécifié;
b) peut être un motif généré par le dispositif de stockage; et
c) ne sont pas des données précédemment écrites sur un LBA différent par l'hôte.
Ainsi, ce que votre appareil retourne après fstrimdépend des fonctionnalités qu'il implémente. À moins qu'il ne prenne en charge RZAT, l'hypothèse selon laquelle les données lues à partir d'un périphérique découpé seront uniquement des zéros ne tient pas.
Vous pouvez utiliser hdparmpour vérifier cela:
sudo hdparm -I /dev/sdX | grep -i trim
J'ai effectué quelques tests en utilisant deux SSD, sdaet sdb. Même fabricant, différents modèles, avec une conformité ATA différente:
$ 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
...
Les deux SSD ont un support différent pour 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
Je peux confirmer qu'après la publication fstrim, le lecteur prenant en charge les "Zéros de lecture déterministes après TRIM" (RZAT) semble avoir mis à zéro la partition concernée presque entièrement. Inversement, l'autre lecteur semble avoir mis à zéro (ou autrement remplacé par un modèle hautement compressible) seulement une partie mineure de l'espace libéré.
1 Source en ligne: INCITS 529: Technologies de l'information - Jeu de commandes ATA / ATAPI - 4 (ACS-4)
Remarque sur les tests:
Comme l'a souligné frostschutz dans les commentaires, une lecture après fstrimpeut renvoyer des données à partir du cache du système d'exploitation, et non à partir du périphérique coupé. C'est, par exemple, ce qui s'est passé dans cette qustion .
(Je voudrais également souligner cette réponse à la même question pour une méthode alternative pour tester TRIM).
Entre fstrimet une lecture ultérieure, vous devrez peut-être supprimer le cache, par exemple avec:
echo 3 | sudo tee /proc/sys/vm/drop_caches
Selon la taille de la partition avec laquelle vous jouez, ne pas supprimer le cache peut suffire à l'échec de vos tests.
Remarque sur votre configuration:
L' discardoption de montage permet un TRIM continu, c'est-à-dire à tout moment où les fichiers sont supprimés. Il n'est pas requis par fstrim. En effet, le TRIM à la demande et le TRIM continu sont deux façons distinctes de gérer les opérations de TRIM. Pour plus d'informations, je voudrais indiquer Solid State Drive sur le Wiki Arch Linux, qui a une couverture détaillée de cette question.
dmsetup table | grep allow_discards