TRIM für ZFS auf FreeBSD committet

[Yamagi]

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:

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>

[Crest]

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

[h^2]

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.

[Yamagi]

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.

[Yamagi]

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.

[Crest]

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

[Yamagi]

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

[namor]

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

Ich hab soweit gefunden, was tunefs(8) dazu sagt:

-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.

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?

[Lord_x]

Ob ZFS es verwendet, kannst du so prüfen:

zdb | grep ashift

Bei einer "9" wird es nicht verwendet und bei einer "12" ist es aktiv.

[Yamagi]

"camcontrol identify $device" sagt dir, ob das Medium TRIM unterstützt. Meine Notebook-Festplatte kann natürlich nicht:

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

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

[namor]

Danke Yamagi! Dann werde ich das gleich mal checken.

Zitat von Lord_x

Ob ZFS es verwendet, kannst du so prüfen:

zdb | grep ashift

Bei einer "9" wird es nicht verwendet und bei einer "12" ist es aktiv.

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)

[Lord_x]

Zitat von namor

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)

Das stimmt natürlich! Sorry das habe ich jetzt beim zweiten lesen auch gemerkt!

[lockdoc]

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?

[Yamagi]

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

[lockdoc]

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?