[[Vorlage(Getestet, bionic)]]

{{{#!vorlage Wissen
[:Terminal: Ein Terminal öffnen]
[:sudo: Root-Rechte]
}}}
[[Inhaltsverzeichnis()]]


{{{#!vorlage hinweis
Dieser Artikel ist Teil der Artikelserie [:SSD:], welche das Thema [wikipedia:Solid_State_Drive:Solid State Drives] behandelt.
Dieser Artikel geht in allen Beschreibungen davon aus, dass die SSD als '''/dev/sda''' im System eingebunden ist. Die Befehle müssen bei davon abweichenden Systemen daher gegebenenfalls angepasst werden.
}}}

Dieser Artikel dient als Ergänzung zu [:SSD/TRIM:] und behandelt verschiedene Testverfahren zum Überprüfen der TRIM-Funktion.

= Testen des TRIM der SSD =
Um zu überprüfen, ob eine SSD die TRIM-Funktion unterstützt, nutzt man den folgenden Befehl in einem Terminal [1] mit Root-Rechten [2]:

{{{#!vorlage befehl
sudo hdparm -I /dev/sda | grep -i TRIM
}}}

Im Positivfall enthält die Ausgabe eine der folgenden Zeilen:
{{{	   *	Data Set Management TRIM supported
	   *	Data Set Management TRIM supported (limit N blocks)
           *    Data Set Management TRIM supported (limit unknown)}}}

Der Stern (`*`) zeigt an, dass die Option verfügbar ist. 

Zu beachten ist außerdem, dass es mehrere Typen von SSDs gibt, die sich darin unterscheiden, welche Daten für per TRIM freigegebene Datenblöcke zurückgeliefert werden. Zu erkennen ist der Typ an einer zusätzlichen Ausgabezeile:

 * Typ 1 – liefert beliebige Daten zurück, nicht jedoch die Ausgangsdaten vor TRIM: {{{	   *	Deterministic read data after TRIM}}}
 * Typ 2 – liefert Nullen zurück: {{{	   *	Deterministic read ZEROs after TRIM}}}
 * Typ 3 – keine zusätzliche Ausgabezeile, das Verhalten für freigegebene Datenblöcke ist undefiniert.

= Testen des Kernel-TRIM für SSDs vom Typ 2 =
Nur für SSDs des oben beschriebenen Typ 2 kann man in einem Terminal [1] mit Root-Rechten [2] sehr einfach testen, ob der automatische TRIM (ab [:Kernel:] 2.6.33) funktioniert. Diese Test-Methode funktioniert auch bei Verwendung von [:Software-RAID:] sowie [:LUKS:] oder [:LVM:] jedoch nicht für sogenannte Overlay-Dateisysteme wie etwa [:ecryptfs:] welches auch bei der Verschlüsselung des [:Homeverzeichnis:] über den Ubuntuinstaller verwendet wird.

Für diesen Test wird eine Datei erstellt, sich deren Position auf dem Datenträger gemerkt, danach die Datei gelöscht und die Daten an der gemerkten Position vorher und nachher verglichen. Das folgende Verfahren zeigt, wie man vorgeht:

Zuerst wechselt man in einen Ordner, der auf der SSD liegt, in diesem Beispiel '''"/"''' (das Wurzeldateisystem). Dann erstellt man dort die Testdatei.
{{{#!vorlage befehl
cd /
yes | sudo dd iflag=fullblock bs=1M count=1 of=trim.test
}}}

Nun muss man noch herausfinden, wo die Datei genau liegt, dazu braucht man die Position im Dateisystem und den Gerätenamen, auf dem das Dateisystem liegt.
{{{#!vorlage befehl
filefrag -s -v trim.test
}}}

Dies führt zu so einer ähnlichen Ausgabe:
{{{
Filesystem type is: ef53
File size of trim.test is 1048576 (256 blocks, blocksize [mark]4096[/mark])
 ext logical physical expected length flags
   0       0    [mark]34048[/mark]             [mark]256[/mark] eof
trim.test: 1 extent found
}}}
Wichtige Werte sind hier gelb Markiert. Die Blockgröße 4096 in Bytes, der Offset (Versatz zum Anfang des Gerätes) 34048 in Blöcken und die Anzahl der Blöcke 256. Mit diesen Werten muss man später die Datei vom Datenträger lesen, da sie nach dem Löschen nicht mehr über ihren Dateinamen ansprechbar ist.

Jetzt noch schnell den Gerätenamen bestimmen:
{{{#!vorlage befehl
df trim.test
}}}
Hier sollte folgende Ausgabe erfolgen (das Gerät wurde gelb markiert):
{{{
Dateisystem              1K-Blöcke  Benutzt Verfügbar Verw% Eingehängt auf
[mark]/dev/mapper/Tarsius-root[/mark]  32896880 11722824  20838512   37% /
}}}

Mit diesen (gelb markierten) Werten liest man jetzt die Datei direkt vom Gerät.
{{{#!vorlage befehl
sudo dd bs=[mark]4096[/mark] skip=[mark]34048[/mark] count=[mark]256[/mark] if=[mark]/dev/mapper/Tarsius-root[/mark] | hexdump -C
}}}
Die Ausgabe sollte so aussehen:
{{{
00000000  79 0a 79 0a 79 0a 79 0a  79 0a 79 0a 79 0a 79 0a  |y.y.y.y.y.y.y.y.|
*
256+0 Datensätze ein
256+0 Datensätze aus
1048576 Bytes (1,0 MB) kopiert, 0,0255604 s, 41,0 MB/s
00100000
}}}
Nun kann man die Datei löschen.
{{{#!vorlage befehl
sudo rm trim.test
sync
}}}
Sollte man in den Mountoptionen (fstab) kein `discard` verwenden muss man noch manuell trimmen.
{{{#!vorlage befehl
sudo fstrim -v ./
}}}

Das Dateisystem sollte jetzt getrimmt worden sein und nun wird mit dem Befehl von weiter oben die (gelöschte) Datei erneut gelesen. Hierbei müssen diesmal zunächst Caches geleert werden, um sicherzustellen, dass die Daten erneut von der SSD gelesen werden.

{{{#!vorlage befehl
echo 1 | sudo tee /proc/sys/vm/drop_caches
sudo dd bs=[mark]4096[/mark] skip=[mark]34048[/mark] count=[mark]256[/mark] if=[mark]/dev/mapper/Tarsius-root[/mark] | hexdump -C
}}}

Ist die Ausgabe die gleiche wie oben (eine Zeile mit `y.y.y.y.y.y.y.y.`) dann wurde nicht getrimmt, hat sich die Ausgabe geändert, dann war der Trim erfolgreich. Hier noch zwei Beispiele für die Ausgabe mit Verschlüsselung
{{{
00000000  1f c9 55 7d 07 15 00 d1  4a 1c 41 1a 43 84 15 c0  |..U}....J.A.C...|
00000010  24 35 37 fe 05 f7 43 93  1e f4 3c cc d8 83 44 ad  |$57...C...<...D.|
00000020  46 80 c2 26 13 06 dc 20  7e 22 e4 94 21 7c 8b 2c  |F..&... ~"..!|.,|
00000030  1f 48 0e 4e 30 f3 63 e1  15 b8 aa 1e d3 ec ef 48  |.H.N0.c........H|
...
}}}
und ohne Verschlüsselung
{{{
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
}}}

= Links =
 * [:SSD/TRIM:] - Hauptartikel
 * [:SSD:] {Übersicht} Übersichtsartikel

#tag: Hardware, System, Installation