TRIM für ZFS auf FreeBSD committet
 

Ein oft nachgefragtes bis schmerzliches vermisstes Feature von ZFS war bisher die dateisystemseitige Unterstützung von TRIM. TRIM markiert auf SSD gelöschte Blöcke als frei, greift somit der integrierten Garbage Collection unter die Arme und ermöglicht es ihr, folgende Schreibvorgänge besser über die einzelnen Flash-Speicherzellen zu verteilen. Dies erhöht theoretisch die Lebensdauer und führt aufgrund der Anwendbarkeit besserer Schreibstrategien zu höherer Schreibgeschwindigkeit. Zwar kann man bei aktuellen SSD aufgrund von Fortschritten in der Firmware streiten, wie notwendig TRIM wirklich noch ist, jedoch schadet es keinesfalls.

In den letzten Monaten hat Pawel Jakub Dawidek zusammen mit den "ZFS on Linux"-Entwicklern daher TRIM-Unterstützung für ZFS entwickelt. Dies ist das erste nicht triviale Feature, was ohne Hilfe von Oracle zustande gekommen ist. Die Umsetzung ist relativ kompliziert, es läuft darauf hinaus, dass freigegebene Blöcke in einer Datenstruktur gesammelt und ab und an auf einmal geTRIMt werden. Grund hierfür ist, dass ein TRIM auf den meisten SSD extrem lange dauert und daher einen nennenswerten Performance-Einfluss hat. TRIM wird dabei auf alle Teile von ZFS angewandt, also Datastores (Medien in vdev), Cache-Devices und Log-Devices. TRIM wird automatisch für jedes Medium genutzt, was es unterstützt, kann allerdings global per sysctl abgeschaltet werden. Entsprechende Medien werden beim Erstellen eines Pools einmalig geTRIMt, d.h. alle freien Blöcke werden bei dieser Operation für die SSD als frei markiert. Beim Pool-Import werden Cache- und Spare-Devices global geTRIMt.

Dieser neue Code befindet sich vorerst nur in 10-CURRENT. Testen ist erwünscht, von produktivem Einsatz ist jedoch für die ersten Wochen aufgrund der Tiefe der Änderungen abzuraten.

Die Commit-Nachricht:
[code]
Author: pjd
Date: Sun Sep 23 19:40:58 2012
New Revision: 240868
URL: http://svn.freebsd.org/changeset/base/240868

Log:
Add TRIM support.

The code builds a map of regions that were freed. On every write the
code consults the map and eventually removes ranges that were freed
before, but are now overwritten.

Freed blocks are not TRIMed immediately. There is a tunable that defines
how many txg we should wait with TRIMming freed blocks (64 by default).

There is a low priority thread that TRIMs ranges when the time comes.
During TRIM we keep in-flight ranges on a list to detect colliding
writes - we have to delay writes that collide with in-flight TRIMs in
case something will be reordered and write will reached the disk before
the TRIM. We don't have to do the same for in-flight writes, as
colliding writes just remove ranges to TRIM.

Sponsored by: multiplay.co.uk

This work includes some important fixes and some improvements obtained
from the zfsonlinux project, including TRIMming entire vdevs on pool
create/add/attach and on pool import for spare and cache vdevs.

Obtained from: zfsonlinux
Submitted by: Etienne Dechamps <etienne.dechamps@ovh.net>
[/code]

Das Feature ist nicht nur für SSDs spannend sondern, wenn es richtig implementiert ist, auch für Sparse Volumes auf SANs.

Was ich mich schon eine Weile frage ist, ob es für ZFS unter FreeBSD eigentlich automatische Benchmarks gibt!
Ich meine, besonders, da der Parameterraum ja sehr groß ist und bekannt, dass sich bestimmte Sache auf die performance auswirken, wäre es wirklich toll zu wissen, wie stark sich was wann und in welcher Kombination auswirkt; ob ein neues ZFS Regressionen beinhaltet etc.

Das wird besonders wichtig, wenn Solaris sterben sollte und wie hier geschehen, Features einfließen, die u.U. von einer kleineren userbase getestet werden.

Also, zum Benchmarken eignen sich natürlich klassische Dateisystem-Benchmarks wie "bonnie++" wunderbar. Die einfach in ein Script gießen, am besten noch ministat(1) mit einbauen und glücklich sein. Viel wichtiger ist die korrekte Methodik, denn sonst misst man nur seine Caches und nicht das Dateisystem selber. Hier wäre es vielleicht sinnvoll, einmal eine Art Tabelle mit Vergleichswerten zu erstellen, sodass interessierte Nutzer ihre Ergebnisse einordnen können.

Die Regression Tests liegen unter FreeBSD unter /usr/src in tools/regression/zfs und decken vor allem die grundlegende Funktionalität ab. FreeBSD Kernel Test Suite "stress2" ist ebenfalls geeignet, um ZFS zu testen. "ZFS on Linux" und Delphix (eine treibende Kraft hinter IllumOS) haben jeweils eigene Test Suits entwickelt, wie weit sie unter FreeBSD lauffähig sind, weiß ich jedoch nicht.

Auf freebsd-fs@ gibt es eine Diskussion über TRIM. Daraus noch an weiteren Infos:
- TRIM ist per Standardeinstellung abgeschaltet und muss per Eintrag "vfs.zfs.trim_disable=0" in der /boot/loader.conf aktiviert werden.
- TRIM wird automatisch deaktiviert, wenn ein Gerät es nicht unterstützt.
- Die sysctl "kstat.zfs.misc.zio_trim.zio_trim_*" geben Informationen, was ZFS gerade treibt.

Gibt es Infos dazu ob das auch per iSCSI funktioniert? Wäre ja für ZVOLs spannend, die per iSCSI exportiert werden.

Das geht, wenn dein iSCSI-Volume "BIO_DELETE" unterstützt. Leider findet Google dazu nichts, also bleibt wohl nur ein Blick in den Code.

Wie findet man eigentlich heraus, ob TRIM unterstützt wird von einem device?

Ich hab soweit gefunden, was tunefs(8) dazu sagt:
[QUOTE]-t enable | disable
Turn on/off the TRIM enable flag. If enabled, and if the under‐
lying device supports the BIO_DELETE command, the file system
will send a delete request to the underlying device for each
freed block. The trim enable flag is typically set when the
underlying device uses flash-memory as the device can use the
delete command to pre-zero or at least avoid copying blocks that
have been deleted.[/QUOTE]

Das ist ja nun aber nur die FS Seite, wenn das "underlying device" nun kein BIO_DELETE unterstützt passiert wohl einfach nichts? Und wie ist das bei ZFS, wird bei vorhandener BIO_DELETE capability einfach TRIM aktiviert? Kann man das irgendwie überprüfen?

Ob ZFS es verwendet, kannst du so prüfen:
[code]
zdb | grep ashift
[/code]
Bei einer "9" wird es nicht verwendet und bei einer "12" ist es aktiv.

"camcontrol identify $device" sagt dir, ob das Medium TRIM unterstützt. Meine Notebook-Festplatte kann natürlich nicht:
[code]
root@maka:pts/3 ~> camcontrol identify ada0
pass0: <HITACHI HTS545032B9A300 PB3ZC61H> ATA-8 SATA 2.x device
pass0: 300.000MB/s transfers (SATA 2.x, UDMA5, PIO 8192bytes)

protocol ATA/ATAPI-8 SATA 2.x
device model HITACHI HTS545032B9A300
firmware revision PB3ZC61H
serial number 100320PB530416J6H0NT
WWN 5000cca5eddf219f
cylinders 16383
heads 16
sectors/track 63
sector size logical 512, physical 512, offset 0
LBA supported 268435455 sectors
LBA48 supported 625142448 sectors
PIO supported PIO4
DMA supported WDMA2 UDMA5
media RPM 5400

Feature Support Enabled Value Vendor
read ahead yes yes
write cache yes yes
flush cache yes yes
overlap no
Tagged Command Queuing (TCQ) no no
Native Command Queuing (NCQ) yes 32 tags
SMART yes yes
microcode download yes yes
security yes no
power management yes yes
advanced power management yes no 16638/0x40FE
automatic acoustic management no no
media status notification no no
power-up in Standby no no
write-read-verify no no
unload yes yes
free-fall no no
data set management (TRIM) no
[/code]

Ob ZFS es nutzt, sagen dir die "kstat.zfs.misc.zio_trim.zio_trim_*" sysctl.

Danke Yamagi! Dann werde ich das gleich mal checken.

[QUOTE=Lord_x;243801]Ob ZFS es verwendet, kannst du so prüfen:
[code]
zdb | grep ashift
[/code]
Bei einer "9" wird es nicht verwendet und bei einer "12" ist es aktiv.[/QUOTE]

AFAIK war die 9 für 512 byte min-IO und die 12 für 4096 byte min-IO, also für die 4k-Sektor Festplatten von Interesse.. (und hat nichts mit TRIM zu tun)

[QUOTE=namor;243804]AFAIK war die 9 für 512 byte min-IO und die 12 für 4096 byte min-IO, also für die 4k-Sektor Festplatten von Interesse.. (und hat nichts mit TRIM zu tun)[/QUOTE]
Das stimmt natürlich! Sorry das habe ich jetzt beim zweiten lesen auch gemerkt! :ugly:

Wie ist es eigentlich, wenn man auf die SSD ein Geli Container legt und diesen dann als Cache in den Pool einbindet... funktioniert dann TRIM trotzdem?

Nein. geli unterstützt (leider) kein TRIM.

Mist :-(

Jemand eine Ahnung inwieweit das unverschluesselte Cache Device eines Vollverschluesselten ZFS Pools den Inhalt des Pools selber verraet. Also kann man davon einzelne Dateien wiederkonstruieren?