staging.inyokaproject.org

Testen

Dieser Artikel wurde für die folgenden Ubuntu-Versionen getestet:

Dieser Artikel ist mit keiner aktuell unterstützten Ubuntu-Version getestet! Bitte teste diesen Artikel für eine Ubuntu-Version, welche aktuell unterstützt wird. Dazu sind die Hinweise zum Testen von Artikeln zu beachten.

Zum Verständnis dieses Artikels sind folgende Seiten hilfreich:

Hinweis:

Dieser Artikel ist Teil der Artikelserie SSD, welche das Thema 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]:

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.

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.

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 4096)
 ext logical physical expected length flags
   0       0    34048             256 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:

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
/dev/mapper/Tarsius-root  32896880 11722824  20838512   37% /

Mit diesen (gelb markierten) Werten liest man jetzt die Datei direkt vom Gerät.

sudo dd bs=4096 skip=34048 count=256 if=/dev/mapper/Tarsius-root | 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.

sudo rm trim.test
sync 

Sollte man in den Mountoptionen (fstab) kein discard verwenden muss man noch manuell trimmen.

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.

echo 1 | sudo tee /proc/sys/vm/drop_caches
sudo dd bs=4096 skip=34048 count=256 if=/dev/mapper/Tarsius-root | 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  |................|
*

Diese Revision wurde am 4. Mai 2021 19:55 von noisefloor erstellt.
Die folgenden Schlagworte wurden dem Artikel zugewiesen: Hardware, Installation, System, ungetestet