Neues ZFS in FreeBSD 8.0-CURRENT

Yamagi

Possessed With Psi Powers
Staff member
Pawell hat soeben ZFS in FreeBSD 8.0-CURRENT aktualisiert. Dies hebt ZFS von der Version 6 auf die neue Version 13, welche aktuell auch in Solaris ist. Damit nutzen Solaris und FreeBSD wieder die gleiche Codebasis und sind Bug zu Bug kompatibel. Zu den wichtigsten neuen Funktionen gehören:

- Stabiler Betrieb, genügend RAM und korrekte Konfiguration vorausgesetzt.

- Alle bekannten Deadlocks wurden behoben, Prozesse bleiben nicht mehr im Status "ZFS" hängen.

- L2ARC, eine neues optionale Cacheverfahren, welches ZFS in einigen Einsatzzwecken deutlich beschleunigt

- ZFSBoot erlaubt das Starten von Zpools. Unterstützt werden alle Formate außer RaidZ

- chflags(1) wird (eingeschränkt) unterstützt

- Vollständige Integration in Jails

- Deligierte Administration

- Sehr viel mehr

Die Commitmessage:
Code:
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:
	- 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

Quellen:
http://svn.freebsd.org/viewvc/base?view=revision&revision=185029
http://lists.freebsd.org/pipermail/freebsd-current/2008-November/000483.html
 
Ich bin ja immer mit Lob für ein OS ziemich zurückhaltend. Tatsächlich ist es für mich so, dass ich das nutze, was ich momentan am wenigsten Shi**e finde.
Was aber in Current passiert sieht nach nem System aus, wo ich sagen kann "hey, das ist echt Klasse"
Äh, sagts nicht weiter - ihr wisst schon, mein Ruf als Troll und so - aber ich freu mich echt auf 8! :-)
 
Ich finde es erstaunlich wie stark ZFS unter FreeBSD voran kommt. Da wird im Desktop-Bereich deutlich weniger getan. Man denke nur an die fehlenden ACPI Sleep-Modes unter amd64.
 
In FreeBSD 7.1 wird es aber wohl nicht mehr reinkommen, denke ich...oder? Da waren mal Gerüchte...

Ich habe hier momentan ein Raid-Z2 Pool mit ca. 2 TB, den ich als Fileserver laufen lassen will. Bis jetzt läuft alles super stabil und wie gedacht.
Ich hab schon ziemlich viel ausprobiert, aber noch nix kaputt bekommen.

Trotzdem bin ich immer noch etwas unsicher (wg. des experimentellen Status), das Ding produktiv einzusetzen.
Regelmäßige Backups sind selbstverständlich.

Wie sind euere Erfahrungen so?
 
Ich finde es erstaunlich wie stark ZFS unter FreeBSD voran kommt. Da wird im Desktop-Bereich deutlich weniger getan. Man denke nur an die fehlenden ACPI Sleep-Modes unter amd64.

Vielleicht solltest Du dazu einen anderen Thread aufmachen. Für mich sind die meisten dieser Sleep-Modi unbrauchbar. Ich verschlüssele Festplatten. Um das vernünftig ans Laufen zu kriegen, müsste man den Speicherinhalt verschlüsseln und auf die Festplatte dumpen. So etwas war schon mal in Planung. Gerade in Notebooks, wo man so etwas wie Sleep brauchen könnte ist man (fast) verpflichtet dazu alles zu verschlüsseln.
 
Eins nach dem anderen. Es wäre erst mal ganz nett auf den Stand von i386 zu kommen.

Ich vermute S4 ist verschlüsselt machbar, da das System ja quasi direkt ans BIOS übergibt. Und das sollte doch mit dem TCPA-Teil in der Lage sein da was zu reißen.
 
ZFS 13 wird es auf keinen Fall in 7.1 schaffen. RELENG_7 ist zur Zeit im Freeze, da gehen wirklich nur noch Bugfixe ein. Sowas großes wie ZFS muss außerdem erst einige Wochen, besser Monate sacken.
 
vollkommen OT

Vielleicht solltest Du dazu einen anderen Thread aufmachen. Für mich sind die meisten dieser Sleep-Modi unbrauchbar. Ich verschlüssele Festplatten. Um das vernünftig ans Laufen zu kriegen, müsste man den Speicherinhalt verschlüsseln und auf die Festplatte dumpen. So etwas war schon mal in Planung. Gerade in Notebooks, wo man so etwas wie Sleep brauchen könnte ist man (fast) verpflichtet dazu alles zu verschlüsseln.

wie macht apple dass denn bei mac os? da gibts den file-vault, der angeblich das userhome verschlüsselt, aber das ändert ja nichts an dem "ruhezustand", der auch durch zuklappen aufgerufen werden kann, oder?
 
Trotzdem bin ich immer noch etwas unsicher (wg. des experimentellen Status), das Ding produktiv einzusetzen.
Regelmäßige Backups sind selbstverständlich.

Wie sind euere Erfahrungen so?
Ich hab's auf einem privaten Server "produktiv" im Einsatz (mit 7.0-RELEASE). Die erste Stolperfalle: 2GB RAM sind zu wenig. Ich habe es so gelöst, den Kernel-Anteil zu erhöhen und ZFS etwas zu stutzen (siehe http://blog.my-universe.com/archives/107-ZFS-und-Beasty-ein-erster-Erfahrungsbericht.html). Mit Deadlocks kämpfe ich allerdings immer noch, es kommt immer mal wieder vor, dass Prozesse mehrere Minuten lang im Status zfs hängen bleiben und damit die gesamte Maschine blockieren (der Load steigt dabei nicht an, der Scheduler "weiß" nicht, dass er den auf ZFS wartenden Prozess eigentlich zugunsten von nicht auf ZFS wartenden Prozessen zurückstellen könnte und hält damit den gesamten Betrieb auf).

Ich habe jetzt eine zweite Maschine mit 7.1-PRERELEASE aufgesetzt (RELENG_7 von letzter Woche Donnerstag) , allerdings diesmal amd64 und mit deutlich mehr RAM (8 GB). Mal sehen, wie ZFS sich da so schlägt, wenn ich die Größe des Adaptive Replacement Cache und des Virtual Device Cache auf default lasse oder sogar etwas nach oben drehe.

Allerdings muss ich gestehen, dass ich doch ziemlich heiß auf V. 13 bin - hab hier zu Hause ein OpenSolaris (aktueller Snapshot) zum experimentieren. Das System ist zwar buggy wie Sau, aber ZFS als Unterbau macht eigentlich keine Zicken mehr. Hoffentlich gibt's eine Entscheidung, nach dem Release von 7.1 das aktualisierte ZFS nach RELENG_7 reinzuholen...
 
Also, die Version ist 13 ist ebenfalls noch als experimentell gekennzeichnet. Aber da sie in OpenSolaris wohl recht rund läuft, ist das mehr ein Standardhinweis der eher konservativen FreeBSDler als wirklich ein Hinweis auf äußerst problematischen Code. Schon die Version 12, von der es ja ein Patchset gab, war bis auf kleinere Zicken eigentlich problemlos einsetzbar und ließ sich (auf recht großer Hardware) auch mit brachialer Gewalt nicht irgendwie in Bedrängnis bringen. Keine Abstürze, keine Deadlocks.

Mit der Version 6 in 7.0 und 7.1 sieht es anders aus. Stabil kann man es hinbekommen, aber die Deadlocks sind nicht zu vermeiden. Es sind auch schon Personen ZPools abgeraucht, mit vollständigem Datenverlust. Die Kennzeichung als experimenteller Code ist also sinnvoll und man sollte wissen, dass es Probleme geben kann und natürlich Backups haben. Wenn einem diese Dinge klar sind, spricht nichts gegen einen Einsatz.
 
Gibt es schon ein Patchset für Version 13 und FreeBSD 7.1? Ansonst...hat vielleicht jemand noch mal den Link für Patchset Version 12? Ich hab zwar schon was gefunden...allerdings hätte ich es gerne aus vertrauenswürdiger (bestätigt funktionierender) Quelle.

Ausserdem hat das, was ich gefunden habe den Vermerk "i386". Das wird wohl für AMD64 weniger geeignet sein, oder?
 
Es gibt kein offizielles Patchset für ZFS Version 12 oder 13 für RELENG_7. Wenn du neuere Versionen willst musst du -CURRENT nehmen oder aber es selbst rückportieren.
 
In FreeBSD 7.1 wird es aber wohl nicht mehr reinkommen, denke ich...oder? Da waren mal Gerüchte...

Ich habe hier momentan ein Raid-Z2 Pool mit ca. 2 TB, den ich als Fileserver laufen lassen will. Bis jetzt läuft alles super stabil und wie gedacht.
Ich hab schon ziemlich viel ausprobiert, aber noch nix kaputt bekommen.

Trotzdem bin ich immer noch etwas unsicher (wg. des experimentellen Status), das Ding produktiv einzusetzen.
Regelmäßige Backups sind selbstverständlich.

Wie sind euere Erfahrungen so?

Gut. Läuft auf einem Backup-Server der Nachts dutzende von GB schreiben muss und dutzende von snapshots täglich erstellt.
 
Angeblich soll zfsboot mit SVN r185097 nun auch wirklich funktionieren. Wenn jemand mir sagen kann welchen Regentanz ich machen muss um es hinzubekommen wäre ich sehr dankbar. Ich bin anscheinend zu blöd dazu... :)
 
OK, Problem gelöst:
Code:
        # dd if=/boot/zfsboot of=/dev/da0s1 count=1                                   
        # dd if=/boot/zfsboot of=/dev/ds0s1 skip=1 seek=1024
Funktioniert nun. :)
 
Ohne es ausprobiert zu haben: könnte es nicht auch mit dem gepatchten Grub von OpenSolaris funktionieren? (vorausgesetzt, man hat ZFS fest im Kernel drin)
 
Ohne es nun ausprobiert zu haben müsste es theoretisch funktionieren. Tatsächlich scheint zfsboot Code aus dem Grub-Patch zu nutzen. Du baust einen /boot/loader, welcher ZFS versteht. Das ist kein Problem, da gleiches auch für das normale zfsboot nötig ist. Nun Nimmst du den gepatchten Grub, setzt /boot/loader als Kernel und es sollte gehen. ZFS brauchst du dafür nicht im Kernel, es wird ja vom Loader geladen. Tatsächlich kann ZFS gar nicht fest eingebunden werden, es steht nur als Modul zur Verfügung.
 
Back
Top