ZFS wurde nach FreeBSD 7 zurückportier

[Yamagi]

Kip Macy hat heute Nacht ZFSv13 aus FreeBSDs Entwicklungszweig -CURRENT in den Zweig RELENG_7, aus welchem die 7.x Releaseversionen erstellt werden, zurückportiert. Dies betrifft die Solaris und OpenSolaris eingesetzt ZFS Version 13 an sich, sowie eine ganze Reihe zusätzlicher Bugfixes und Fehlerbehebungen in Sachen Deadlocks. Außerdem wurde der unter FreeBSD7/amd64 standardmäßig zur Verfügung stehende Kernelspeicher drastisch erhöht. ZFS sollte unter diesen Plattformen daher ohne extremes Tuning laufen, ein Begrenzen der ARC kann aber weiterhin von Nöten sein. Mit diesen Änderungen stehen nun auch eher konservativen Nutzern, die nicht auf -CURRENT wechseln wollen, die Funktionen aktueller ZFS-Versionen zur Verfügung.

Bleibt die Frage, wie stabil dies ist. Sun verwendet exakt den gleichen Code im produktiven Einsatz. Unter FreeBSD ist er nach wie vor als experimentell gekennzeichnet, aller Voraussicht nach wird er es auch noch für längere Zeit bleiben. Am Ende ist es eine Frage, die jeder mit sich selbst klären muss.

Nach einem Update des Codes sind die ZPool weiterhin auf Version 6. Sie müssen explizit mit dem Befehl "zpool upgrade" auf die neue Version gebracht werden. Aber Achtung! Dieser Vorgang kann nicht rückgängig gemacht werden, einmal aktualisiert ist der Weg zurück auf ein altes ZFSv6 für immer verschlossen! Da die neue Version ZFSv13 auch die alten Pools nutzen kann und auf ihnen deutlich besser als der Code laufen sollte, ist es sehr anzuraten das eigentliche Upgrade erst nach einigen Tagen Testbetrieb durchzuführen!

Die Commit-Nachricht:

Date: Wed, 20 May 2009 23:35:00 +0000 (UTC)
From: Kip Macy <kmacy@FreeBSD.org>
To: src-committers@freebsd.org, svn-src-all@freebsd.org,
        svn-src-stable@freebsd.org, svn-src-stable-7@freebsd.org
Cc:
Subject: svn commit: r192498 - in stable/7: . cddl
        cddl/compat/opensolaris/include cddl/compat/opensolaris/misc
        cddl/contrib/opensolaris/cmd/zdb cddl/contrib/opensolaris/cmd/zfs
        cddl/contrib/opensolaris/cmd...

Author: kmacy
Date: Wed May 20 23:34:59 2009
New Revision: 192498
URL: http://svn.freebsd.org/changeset/base/192498

Log:
  MFC ZFS version 13. This includes the changes by pjd (see original message
  below) as well as the following:

  - the recurring deadlock was fixed by deferring vinactive to a dedicated thread

  - zfs boot for all pool types now works
        Submitted by: dfr

  - kmem now goes up to 512GB so arc is now limited by physmem

  - the arc now experiences backpressure from the vm (which can be too
  much - but this allows ZFS to work without any tunables on amd64)

  - frequently recurring LOR in the ARC fixed

  - zfs send coredump fix

  - fixes for various PRs

  Supported by: Barrett Lyon, BitGravity

  Revision 185029 - (view) (annotate) - [select for diffs]
  Modified Mon Nov 17 20:49:29 2008 UTC (6 months ago) by pjd
  File length: 38244 byte(s)
  Diff to previous 177698

  Update ZFS from version 6 to 13 and bring some FreeBSD-specific changes.

  This bring huge amount of changes, I'll enumerate only user-visible changes:

  - Delegated Administration

         Allows regular users to perform ZFS operations, like file system
         creation, snapshot creation, etc.

  - L2ARC

         Level 2 cache for ZFS - allows to use additional disks for cache.
         Huge performance improvements mostly for random read of mostly
         static content.

  - slog
        
         Allow to use additional disks for ZFS Intent Log to speed up
         operations like fsync(2).

  - vfs.zfs.super_owner

         Allows regular users to perform privileged operations on files stored
         on ZFS file systems owned by him. Very careful with this one.

  - chflags(2)

         Not all the flags are supported. This still needs work.
                                                                
  - ZFSBoot
           
         Support to boot off of ZFS pool. Not finished, AFAIK.

         Submitted by:   dfr

  - Snapshot properties

  - New failure modes

         Before if write requested failed, system paniced. Now one
         can select from one of three failure modes:

         Before if write requested failed, system paniced. Now one
         can select from one of three failure modes:
         - panic - panic on write error
         - wait - wait for disk to reappear
         - continue - serve read requests if possible, block write requests

  - Refquota, refreservation properties

         Just quota and reservation properties, but don't count space consumed
         by children file systems, clones and snapshots.

   - Sparse volumes

         ZVOLs that don't reserve space in the pool.
        
   - External attributes

         Compatible with extattr(2).

   - NFSv4-ACLs

         Not sure about the status, might not be complete yet.

         Submitted by:   trasz

   - Creation-time properties
                                                                
   - Regression tests for zpool(8) command.
           
   Obtained from:        OpenSolaris

[Daemotron]

Als ich das heute morgen gelesen habe, dachte ich bloß "cool" - mit einem Backport hatte ich ehrlich gesagt nicht gerechnet.

v13 habe ich hier mit OpenSolaris in Betrieb und kann nicht meckern - Deadlocks hatte ich in der Konstellation noch nie, und auch ansonsten keine Scherereien (ok, die Kiste läuft auf x86_64 und hat genügend RAM). Die Frage ist ja bloß, ob der ZFS-Code sich im FreeBSD-Kernel genauso verhält wie im (Open)Solaris-Kernel, oder ob die unterschiedliche Implementierung der diversen anderen Subsysteme hier zu Seiteneffekten führt. Hmm, nachher mal eine qemu-Instanz mit RELENG_7 aufsetzen und testen

[nakal]

Ich hatte ZFS im Betrieb auf CURRENT mit v13. Meine Begeisterung hat sich gelegt, als ich nach 6 Monaten auf einen kompletten Zpool nicht mehr zugreifen konnte. Dies ist schon mehreren Leuten passiert. Keiner weiß so genau was da los ist. In dieser Situation ist der Zpool komplett unbrauchbar und es gibt keine Workarounds um noch etwas daran zu reparieren, außer ein Backup zu verwenden.

Ich habe dann vor kurzem zurück auf UFS gestellt und kann nun besser schlafen. Das soll nur eine kleine Warnung sein, damit ihr auch Backups von diesem experimentellen Dateisystem macht.

[cla]

" FreeBSDs Entwicklungszweig -CURRENT in den Zweig RELENG_7, aus welchem die 7.x Releaseversionen erstellt werden, zurückportiert."

Dann ist der neue Code -13 also im nächsten Release 7.3 enthalten? Oder hab ich da jetzt was falsch verstanden?

"Meine Begeisterung hat sich gelegt, als ich nach 6 Monaten auf einen kompletten Zpool nicht mehr zugreifen konnte. Dies ist schon mehreren Leuten passiert."

Hast du diesbezüglich mehr Informationen oder Links zu ähnlichen Vorfällen?

[Yamagi]

Ja, er wird in 7.3 sein. Allerdings wird 7.3 wohl in etwa zeitgleich mit 8.0 erscheinen.

[Yamagi]

So, ich habe den neuen Code - ein 7-STABLE von gestern Morgen ca. 09:00 Uhr - jetzt mehr als 24 Stunden lang getreten. Die Maschine läuft unter FreeBSD/amd64 und hat 4GB RAM. Bonnie++, kopieren der Ports, paralleles löschen, kopieren großer Dateien, etc. Stürzte die alte ZFS-Version unter dieser Last trotz Tuning schon nach wenigen Minuten ab, läuft die neue Version ohne irgendwelche Einträge in /boot/loader.conf stabil. Sie tut dies auch, wenn der Arbeitsspeicher auf nur 1GB begrenzt ist. Auch gab es keiner Deadlocks oder sonstiges, ungewolltes Verhalten.

[nakal]

Zitat von cla

"Meine Begeisterung hat sich gelegt, als ich nach 6 Monaten auf einen kompletten Zpool nicht mehr zugreifen konnte. Dies ist schon mehreren Leuten passiert."

Der Panic, den ich erhalten habe ist sehr grundlegend und weist auf die Zerstörung von Meta-Informationen zum ZPool. Da kann man eher nichts mehr retten.

http://www.google.de/search?hl=de&cl...nG=Suche&meta=


Was ich auf dem Server gemacht habe ist folgendes:

• Ich hatte ein Pool auf einem Hardware-RAID.
• Pool wurde automatisch beim Starten importiert und mehrere ZFS-Dateisysteme gemountet.
• Es wurde regelmäßig (jede Stunde) ein Snapshot gemacht. Dazu habe ich den Port sysutils/zfs-snapshot-mgmt verwendet. Dieser Port sorgt dafür, dass Snapshots nicht nur erstellt, sondern auch aufgeräumt werden (vielleicht ist das hier das kritische Ereignis, das kann ich nur vermuten).
• Die ZFS-Verzeichnisse und Snapshot-Verzeichnisse wurden ebenfalls per Samba sichtbar gemacht. So konnte jeder auf ältere Snapshots zugreifen, falls ein Unglück passiert. Eigentlich eine nette Sache.
• Zur Zeit des Panics war hohe I/O-Last auf dem Server (ZFS wurde beschrieben). Da hat wohl auch jemand versucht in ein Snapshot-Verzeichnis zu schreiben (per Samba) was wohl nicht ging, das habe ich vor kurzem erst gesagt bekommen. Vielleicht hat der Server auch gleichzeitig einen Snapshot gemacht oder einen zerstört. Backup wurde währenddessen nicht gemacht.

[martinm]

Bitte nicht vergessen, dass sich nicht nur die Pool-Version, sondern auch die Version der Dateisysteme geändert hat.

Daher nicht nur zpool upgrade auf alle Pools, sondern auch zfs upgrade auf alle shares.

Es gibt auch sowas wie ein ChangeLog für die ZFS Pools und Dateisysteme, und zwar kann mann die Änderungen zwischen v6 und v13 hier nachlesen:
Änderungen in ZFS Version 7
Änderungen in ZFS Version 8
Änderungen in ZFS Version 9
Änderungen in ZFS Version 10
Änderungen in ZFS Version 11
Änderungen in ZFS Version 12
Änderungen in ZFS Version 13

Was uns in der nächsten Zukunft erwartet:
Änderungen in ZFS Version 14
Änderungen in ZFS Version 15

Änderungen im ZPL zwischen v1 und v3:
Änderungen in ZPL Version 2
Änderungen in ZPL Version 3

Und wieder Vorschau auf das Kommende:
Änderungen in ZPL Version 4