ATA Trim Performance

Aus Thomas-Krenn-Wiki
Wechseln zu: Navigation, Suche

ATA Trim ist von SSD zu SSD unterschiedlich implementiert. Es hängt jeweils vom jeweiligen SSD Modell (Hersteller/Typ) ab, wie lange ein TRIM für eine bestimmte Anzahl an Sektoren dauert. Die Linux Entwickler nahmen dieses Verhalten zum Anlass, neben dem normalen Onlince-Discard (das ein ATA Trim sofort ausführt wenn etwa eine Datei gelöscht wird) auch ein Batched Discard zu implemeniteren. Bei Letzterem wird ATA Trim manuell durchgeführt, wenn der Benutzer ein entsprechendes Kommando (fstrim) ausführt.

Auswirkungen der ATA Trim Performance

Beim Formatieren von SSDs führen mittlerweile viele Betriebssysteme ein Trim über den gesamten Datenbereich aus. Wenn eine SSD sehr lange für Trim benötigt, steigt damit die notwendige Zeit für das Formatieren.

Hinweis: Wie die jeweiligen SSD Modelle TRIM genau implementieren wird von den Herstellern leider nicht dokumentiert. Es ist daher möglich, dass bei SSDs bei denen das Formatieren mit Trim sehr schnell geht der Controller anschließend im Hintergrund noch SSD Blöcke löscht[1] oder dass sich SSD Controller merken welche Blöcke tatsächlich zu löschen sind (und somit Datenbereiche, die zwar eine TRIM Anforderung bekommen aber ohnedies gelöscht sind, nicht nochmals löschen). Somit könnte die Performance nach erfolgten Trim trotzdem noch kurzzeitig negativ beeinflusst werden. Um solche Performance-Auswirkungen im laufenden Betrieb sicher auszuschließen, ist ein Batched Discard (etwa einmal Nachts per Cronjob) dem Online Discard vorzuziehen.

Tests

Die folgende Tabelle zeigt die gemessene Zeit für das Formatieren einer 100 GB Partitionen mit einem Ext4 Dateisystem. Als Testsystem kam ein Fedora 15 64 Bit Live-System zum Einsatz.

SSD Dauer Formatieren
einer 100 GB Partition
Intel 320 Series SSD 160 GB 1,1s
Intel 510 Series SSD 120 GB 6,3s
Samsung 470 Series SSD 128 GB 1,6s
OCZ Vertex 2 3,5" SSD 115 GB 1m 29,3s
OCZ Vertex 3 SSD 120 GB 1m 16,6s

Anmerkungen

Dass die langen Pausen tatsächlich auf die Trim Performance zurückzuführen sind, bestätigte ein Aufruf mit strace. Die Wartezeit war jeweils beim ioctl BLKDISCARD:

[root@localhost dev]# strace mkfs.ext4 /dev/sda1
execve("/sbin/mkfs.ext4", ["mkfs.ext4", "/dev/sda1"], [/* 26 vars */]) = 0
brk(0)                                  = 0x8ef000
[...]
open("/dev/sda1", O_RDWR)               = 4
ioctl(4, BLKDISCARD, {0, 7f4043bad800}

Die Option -v gibt auch ohne strace einen Hinweis auf Trim (Calling BLKDISCARD) - hier dazu ein weiteres Beispiel:

[root@localhost ~]# time mkfs.ext4 -v /dev/sdb1
mke2fs 1.41.14 (22-Dec-2010)
fs_types for mke2fs.conf resolution: 'ext4'
Calling BLKDISCARD from 0 to 107374182400 succeeded.
Filesystem label=
OS type: Linux
Block size=4096 (log=2)

Einzelnachweise

  1. Re: Testing TRIM with LVM (Zdenek Kabelac, linux lvm mailing list, 13.04.2011) Note: this drive (unlike many others) is processing TRIM command on background. So 'traditional' benchmark do not provide valuable results. (As we've been evaluating this drive somewhat to compare with Intel). Outcome is - when you issue TRIM command - it's immediately finished - but the performance of drive is temporarily decreased while the drive is performing block trimming for some time. Thus you might get 'impressive' results when some benchmarks are evaluating TRIM performance ;)


Foto Werner Fischer.jpg

Autor: Werner Fischer

Werner Fischer, tätig im Bereich Communications / Knowledge Transfer bei Thomas-Krenn, hat sein Studium zu Computer- und Mediensicherheit an der FH Hagenberg abgeschlossen. Er ist regelmäßig Autor in Fachzeitschriften und Speaker bei Konferenzen wie LinuxCon, OSDC, OSMC, LinuxTag u.v.m. Seine Freizeit gestaltet er sehr abwechslungsreich. In einem Moment absolviert er seinen Abschluss im Klavierspielen, im anderen läuft er beim Linzmarathon in der Staffel mit oder interessiert sich für OpenStreetMap.


Das könnte Sie auch interessieren

Samsung PM853T SSDs
Solid-State Drive
SSD Over-Provisioning mit hdparm