ATA Trim Performance

Aus Thomas-Krenn-Wiki
Zur Navigation springen Zur Suche springen

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 Online-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 arbeitet im Product Management Team von Thomas-Krenn. Er evaluiert dabei neueste Technologien und teilt sein Wissen in Fachartikeln, bei Konferenzen und im Thomas-Krenn Wiki. Bereits 2005 - ein Jahr nach seinem Abschluss des Studiums zu Computer- und Mediensicherheit an der FH Hagenberg - heuerte er beim bayerischen Server-Hersteller an. Als Öffi-Fan nutzt er gerne Bus & Bahn und genießt seinen morgendlichen Spaziergang ins Büro.


Das könnte Sie auch interessieren

Consumer versus Enterprise SSDs
KIOXIA CM6-V U.3 NVMe SSDs
SSD Performance optimieren