TRIM und ZFS

minimike

minimike

Berufsrevolutionär
Hi

Ich habe auf einem Server mit zwei SSD's für das System dieses in einem ZFS Pool (mirror) installiert. OS ist FreeBSD 9.2. Gibt es was zu Beachten damit TRIM läuft?

root@mightychicken:/usr/ports # zpool get all systempool
NAME PROPERTY VALUE SOURCE
systempool size 222G -
systempool capacity 0% -
systempool altroot - default
systempool health ONLINE -
systempool guid 12653365732309938587 default
systempool version - default
systempool bootfs systempool/root local
systempool delegation on default
systempool autoreplace off default
systempool cachefile - default
systempool failmode wait default
systempool listsnapshots off default
systempool autoexpand off default
systempool dedupditto 0 default
systempool dedupratio 1.00x -
systempool free 221G -
systempool allocated 1.41G -
systempool readonly off -
systempool comment - default
systempool expandsize 0 -
systempool freeing 0 default
systempool feature@async_destroy enabled local
systempool feature@empty_bpobj active local
systempool feature@lz4_compress enabled local
 
foxit schrieb:
FreeBSD 9.2 liefert auch bei einer "normalen" HDD den Wert "1".
Zum Vergrößern anklicken....
Auch wieder wahr.

Also besser gucken, ob die Werte hier nicht null sind:
Code: 
kstat.zfs.misc.zio_trim.bytes: 0
kstat.zfs.misc.zio_trim.success: 0
kstat.zfs.misc.zio_trim.unsupported: 105
kstat.zfs.misc.zio_trim.failed: 0
 
Hmm

Code: 
root@mightychicken:~ # sysctl kstat.zfs.misc.zio_trim.bytes
kstat.zfs.misc.zio_trim.bytes: 136924160
root@mightychicken:~ # sysctl kstat.zfs.misc.zio_trim.success
kstat.zfs.misc.zio_trim.success: 9496
root@mightychicken:~ # sysctl kstat.zfs.misc.zio_trim.unsupported
kstat.zfs.misc.zio_trim.unsupported: 132
root@mightychicken:~ # sysctl kstat.zfs.misc.zio_trim.failed
kstat.zfs.misc.zio_trim.failed: 0

Bei kstat.zfs.misc.zio_trim.failed ist das jetzt gut oder schlecht?
 
Ja, dein TRIM funktioniert: 136924160 Bytes wurden in 9496 Requests erfolgreich geTRIMt. 132 TRIM-Requests schlugen fehl, entweder ist ein Pool mit klassischen Platten im System oder die Bedingungen der SSD für TRIM waren nicht erfüllt. Moderne SSD stellen aber kaum mehr welche. Im Fall von Festplatten wurde das TRIM auf dem Pool automatisch deaktiviert.
 
Selbst bei einem RAID-Z3 wäre das bescheuert. Das gibt zu wenige IOPS und Backupseinspielen dürfte schneller sein als ein Resilvern. Klingt als hätte nen D.A.U. die Gier nach mehr TB gepackt.
 
Na ihr Neidhammel. Ich habe produktiv 16 x 3000 Platten für Backups in einem RaidZ1. Und ich spiele mit weiteren 16 Platten rum die ich mal für iSCSI benutzen will. Wer hat geschrieben das ich mehr als 7 VDEVS in einem RaidZ benutze?
 
Wahrscheinlich hast du das gleiche Setup wie ich auf meinen 24-Port Machinen. Im Moment fahre ich darauf ZFS auf 20 Platten (zuzüglich 2x Systemspiegel, Hotspare und Log/Cache-Device), unterteilt in vier RAIDZ2 mit jeweils 5 Platten. RAIDZ1 kann man natürlich auch machen, aber das war mir hinsichtlich Zuverlässigkeit zu unsicher. Gerade, da es immer etwas Nervenkitzel ist die nicht mehr ganz so neuen 15k HDDs wieder einzuschalten, wenn die Kiste aus welchen Gründen auch immer mal aus musste. Eventuell muss da mal über SSDs nachgedacht werden...
 
Auf meinen Storage Maschinen z.B. owncloud, wo mir Platz wichtiger war, habe ich zwei vdevs (raidz-2) mit je 10 Platten erstellt und auf den performance relevanten Kisten wie NFS server, wo es auf Platz nicht so ankommt 4x5 und ein log device. Bisher funktioniert das so sehr gut, obwohl ein resilvering auf 10 Platten wahrscheinlich auch lange dauern wuerde. Hat da jemand Erfahrung? Bisher *mit der Pfote auf Holz klopf* musste ich das noch nicht.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben