Deine Logik ist nicht falsch. Sie ist jedoch nur gültig, wenn einige Bedingungen erfüllt sind.
Der Befehl TRIM , wie im ATA-Befehlssatz angegeben , kann die Sektoren, für die er ausgegeben wird, auf Null setzen oder nicht.
Tatsächlich konzentriert sich der Standard darauf, welche Daten nach der Ausgabe von TRIM 1 zurückgegeben werden müssen :
Die folgenden Verhaltensweisen sind in dieser Norm für Sektoren festgelegt, die das Gerät abschneidet (siehe 7.5.3.3):
a) nicht deterministisch - die Daten als Antwort auf ein Lesen aus einem zugeschnittenen Sektor können sich für jedes Lesen ändern, bis der Sektor vom Host geschrieben wird;
b) Deterministisches Lesen nach dem Zuschneiden (DRAT) - Die Daten, die als Antwort auf ein Lesen eines zugeschnittenen Sektors zurückgegeben werden, ändern sich nicht, können sich jedoch von den zuvor zurückgegebenen Daten unterscheiden. und
c) Nullen nach dem Zuschneiden lesen (RZAT) - die Daten, die als Antwort auf ein Lesen des zugeschnittenen Sektors zurückgegeben werden, sind Null.
[...] Sowohl für DRAT- als auch für nicht deterministische Speichergeräte werden die Daten als Antwort auf einen Lesebefehl an eine LBA zurückgegeben, die erfolgreich gekürzt wurde:
a) können die zuvor zurückgegebenen Daten für die angegebene LBA sein;
b) kann ein von der Speichervorrichtung erzeugtes Muster sein; und
c) es handelt sich nicht um Daten, die zuvor vom Host in eine andere LBA geschrieben wurden.
Daher fstrimhängt es von den implementierten Funktionen ab , wonach Ihr Gerät zurückkehrt . Sofern RZAT nicht unterstützt wird, gilt die Annahme, dass die von einem zugeschnittenen Gerät gelesenen Daten nur Nullen sind, nicht.
Sie können Folgendes hdparmüberprüfen:
sudo hdparm -I /dev/sdX | grep -i trim
Ich habe einige Tests mit zwei SSDs durchgeführt sdaund sdb. Gleicher Hersteller, verschiedene Modelle, mit unterschiedlicher ATA-Konformität:
$ 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
...
Die beiden SSDs unterstützen TRIM unterschiedlich:
$ 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
Ich kann bestätigen, dass fstrimdas Laufwerk, das "Deterministic read ZEROs after TRIM" (RZAT) unterstützt, die betroffene Partition nach der Ausgabe fast vollständig auf Null gesetzt zu haben scheint. Umgekehrt scheint das andere Laufwerk nur einen kleinen Teil des freigewordenen Speicherplatzes auf Null gesetzt zu haben (oder auf andere Weise durch ein stark komprimierbares Muster ersetzt zu haben).
1 Online-Quelle: INCITS 529: Informationstechnologie - ATA / ATAPI-Befehlssatz - 4 (ACS-4)
Hinweis zum Testen:
Wie frostschutz in Kommentaren anmerkt , kann ein Read After fstrimDaten aus dem Cache des Betriebssystems und nicht aus dem gekürzten Gerät zurückgeben. Es ist zum Beispiel das, was in dieser Frage passiert ist .
(Ich würde auch auf diese Antwort auf dieselbe Frage für eine alternative Methode zum Testen von TRIM verweisen ).
Zwischen fstrimund einem nachfolgenden Lesevorgang müssen Sie möglicherweise den Cache löschen, z. B. mit:
echo 3 | sudo tee /proc/sys/vm/drop_caches
Abhängig von der Größe der Partition, mit der Sie spielen, reicht es möglicherweise aus, den Cache nicht zu löschen, damit Ihre Tests fehlschlagen.
Hinweis zu Ihrem Setup:
Die discardMount-Option ermöglicht kontinuierliches TRIM, dh jedes Mal, wenn Dateien gelöscht werden. Es ist nicht erforderlich von fstrim. Tatsächlich sind On-Demand-TRIM und Continuous-TRIM zwei verschiedene Methoden, um TRIM-Operationen zu steuern. Für weitere Informationen verweise ich auf Solid State Drive im Arch Linux Wiki, in dem dieses Thema ausführlich behandelt wird.
dmsetup table | grep allow_discards