ZFS - einige Fragen!

soul_rebel

ist immer auf der flucht
Also es wird ja gerade in vielen Threads von ZFS geschwärmt und es gibt da ein paar fragen, die lassen mich nicht los:
1) Brauch ich für ZFS wirklich 1GB Ram? Wieso überhaupt verbraucht ein Dateisystem so verdammt viel? Und vor allem, wenn ich für ZFS 1GB Ram brauche, brauche ich dann noch mehr wenn das System nochwas tut außer ZFS-Partitionen haben? (meinen Server wollte ich sowieso auf 1GB aufrüsten, aber wenn das nichtmal reicht...im Moment kommt er mit 256MB aus)

2) Ein weiter Bonus bei ZFS ist ja, dass logische und primären DOS-Partitionen mit ZFS auch von Linux, Solaris und OSX gelesen und beschrieben werden können. Wenn ich eine GPT-partition als Pool-container verwende geht das denke ich nicht, oder? Wird FreeBSD denn auch (weiterhin) ZFS auf primären DOS-Partitionen unterstützen?

3) Die eigene Verschlüsselung von ZFS ist ja noch nicht stabil(oder?), deswegen habe ich vor auf einigen Systemen einfach .eli-Devices als Pool-Container zu nehmen (außerdem vertraue ich BSD-Encryption einfach mehr als SUN ;) ). Das sollte ja soweit kein Problem sein (außer dass es dann natürlich nicht X-platform ist). Davon kann ich dann allerdings nicht booten, oder? (also /boot muss je eh unverschlüsselt sein...).

4) Ich hab ja schon viel über inkrementelle Snapshots und RAID und sowas gelesen, aber das ist mir eigentlich zu kompliziert und Platz dafür habe ich auch keinen. Im Moment sichere ich Daten einfach auf Wechselplatten gleicher größe mit RSYNC. Das erhöhrt außerdem die Lebenszeit der Backup-platten, da sie nur selten an sind. Gibt es von sowas auch was eingebautes bei ZFS oder würdet ihr empfehlen einfach einen zweiten pool auf den Backup-platten einzurichten und das Dateisystem wie gehabt mit RSYNC zu spiegeln?

So... das wars erstmal aber mirfällt bestimmt noch was ;)
 
Chaosradio Express

In der letzten Chaosradio-Express-Folge wurde das alles abgearbeitet. Glaub ich.
Irgendwann wurde es zuviel Voodoo, da bin ich nimmer mitgekommen. Der Snapshot-Kram wird aber begeistert erläutert.

http://chaosradio.ccc.de/cre049.html

zu 1) es ist wohl verdammt schwierig, mit ZFS Daten zu verlieren bzw. gibt´s einen Haufen Features die dafür Sorge tragen, dass man ZFS Filesystem(e) evtl. nur noch mit Nukleargewalt kleinkriegt. Ausserdem kann damit sogar Mondbasen mounten und Pete Doherty entgiften. Das kostet Performance und Speicher, mal so grob überschlagen. Irgendwas ist halt immer.
 
Erstmal allgemein: Wenn auch noch nicht fertig (ich muss erstmal auf 7.0-BETA1 aktualisieren und dann weitersehen), solltest du dir mal http://wiki.bsdforen.de/zfs anschauen. Des weiteren sei dir http://wiki.bsdforen.de/howto/zfs empfohlen :)

1) ZFS benötigt soviel RAM, weil es sehr stark mit Buffern und Hashtabellen im Speicher arbeitet. Der Speicherhunger ist wirklich so enorm, wie man sagt. Ich würde es unter FreeBSD/amd64 mit 1GiB RAM erst gar nicht anfassen. Allerdings soll es dank der letzten Änderungen inzwischen auf bei FreeBSD/i386 512MiB RAM laufen, wenn auch nur langsam. Im letzten Fall muss man aber an Sysctl drehen (sie Links oben).

2) Theoretisch soll es gehen. Wie es derzeit ausschaut, weiß ich nicht, für 7.1 ist die Funktionalität der GPT für ZFS aber geplant. Damit wäre es dann auch möglich, dass das System anhand des Partitionsidentifiers erkennt, zu welchem Pool die Partition gehört und welchen Zustand (aktiv, inaktiv, nicht importiert) dieser hat. Auf primären DOS-Partitionen ist ZFS auch möglich, das DIng läuft auf allem was ein Blockdevice ist :)

3) ZFS eigene Verschlüsselung ist noch Beta und in FreeBSD AFAIR gar nicht enthalten. Du musst also ELI nehmen. Siehe dazu auch die Links oben. Booten kannst du im Augenblick von ZFS nicht, dies soll erst mit 7.1 unterstützt werden. Allerdings wird es auch dann nicht von einem verschlüsselten Pool und nicht von einem RAIDZ klappen.

4) ZFSs Snapshots sind "billig", sprich schnell und brauchen kaum Platz dank "Copy on Write". Er schreibt die Daten erst in den Snapshot, wenn sie sich ändern. RAID werden verschiedene Level unterstützt, RAID-1 und RAID-Z1 (mind. 3 Platten, eine darf ausfallen) sowie RAID-Z2 (mind 5 Platten, 2 dürfen ausfallen). EIn Backup ersetzt das natürlich nicht. Rsync läuft inzwischen mit ZFS, an die Stelle von Dump tritt "zfs send".

So, das war jetzt schnell und unpersönlich runtergerattert, aber ich hoffe es hilft dir :)
 
Zuletzt bearbeitet:
es ist wohl verdammt schwierig, mit ZFS Daten zu verlieren bzw. gibt´s einen Haufen Features die dafür Sorge tragen, dass man ZFS Filesystem(e) evtl. nur noch mit Nukleargewalt kleinkriegt

Das stimmt schon, aber gegen Hardwareschäden (z.B. durch Blitzschlag) ist ZFS ziemlich machtlos ;)
 
Das Problem ist, dass ZFS ein ziemlich komplexes Dateisystem ist, vor allem im Vergleich zu zum Beispiel FFS und seinen Inkarnationen. Derzeite startet FreeBSD (simpel erklärt) so:
1. Im Masterbootrekord liegt boot0. Dies wird vom BIOS in den Speicher geladen und ausgeführt.
2. Boot0 sucht sich den aktiven oder dem von Nutzer ausgewählten Slice und lädt aus seinem zweiten Sektor boot1. boot1 versteht genug UFS um /boot/loader zu laden und auszuühren.
3. /boot/loader lädt den Kernel und seine Module in den RAM und startet dann den Kernel. Der Kernel bootet durch, läuft dann den Bootcode der Module ab (das ist der Großteil der dmesg), hängt das Root ein und springt schließlich in den Kernelprozess 0 "swapper".
4. "swapper" ist im wesentlichen der Scheduler. Dieser führt auf dem bereits bei Boot angelegten ersten Userlandprozess 1 ein "exec /sbin/init" aus und legt diesen auf die CPU. Init überprüft, in welchen Modi das System gestartet wurde. Ist es Single User, forkt init sich einmal in /bin/sh. Ist es Multiuser wird "/bin/sh /etc/rc" ausgeführt. Die rc-Scripte laufen durch und du endest am Login.

Das Problem bei ZFS besteht an drei Stellen:
1) boot0 muss so modifiziert werden, dass er mehr als 7,5KiB laden kann. Für das klassische boot2 ist dies ausreichend, die ZFS-Logik benötigt aber deutlich mehr Platz.
2) Anstelle von boot2 muss ein Zboot treten, welches die Pools im System einlesen kann, den mit "Alternativ Root /" finden, auf ihm den korrekten Datensatz suchen und in diesem /boot/loader finden.
3) /boot/loader muss ebenfalls genug ZFS sprechen um den Kernel zu finden und zu laden.
Nicht zuletzt ist eines der ganz großen Probleme dabei, dass man an diesen Stellen kein CDDL Code nutzen kann, was eine Neuimplementation eines minimalen Teils von ZFS nach sich zieht.

Diese Schritte wurden bereits gemacht und der Code ist im Perforce zu finden. Wie ich an anderer Stelle bereits schrieb, sind gestern Abend nötige Vorarbeiten (der neue boot0 und gptboot) in HEAD eingegangen, sodass ZBoot und der neue loader sicherlich in kürze folgen werden. Da das Ziel ist zu 7.1 ZFS vollständig zu unterstützen (7.0 hat es nur Experimental), wird der ganze Kram sicher auch einen MFC bekommen :)
 
ZFS rennt auch mit 256MB RAM, wie man der ML entnehmen kann. Bernd Walter hat es so am laufen. Natürlich darf man hier keine Wunder erwarten, und ich würde es für ein produktives System auch nicht empfehlen.

Desweiteren wäre AMD64 zu empfehlen, auf 32bittern läuft es auch, allerdings muss man hier in die Tuningtrickkiste greifen, wie um wiki von FreeBSD beschrieben. Und, auch damit kann es immer wieder, ich teste ZFS nun schon geraume Zeit, zu Panics kommen, auch das beschreibt die ML hier ausgiebig.
Gerade bei grösseren rsync Läufen von einigen GB, semmelt mir die Kiste (dual XEON 3.06 mit 2GB RAM) immer wieder ab.
 
Hatte Pawel das absemmeln beim rsync nicht behoben? Er hatte doch letztens irgendwas in die Richtung auf freebsd-current@ geschrieben...
 
Hatte Pawel das absemmeln beim rsync nicht behoben? Er hatte doch letztens irgendwas in die Richtung auf freebsd-current@ geschrieben...

Leider nein. Ich kann dies auch nur immer auf rsync schieben, da die Kiste einen solchen in der Nacht macht und am nächsten morgen steht.

Leider kann ich, aus Zeitmangel, keinen anständigen dump und Fehlerbericht zimmern, aber das Problem ist ja bekannt.
Auch das man, wie um FBSD wiki bei ZFS und tuning geschrieben, mit den Werten etwas "spielen" muss. Ich habe noch keine optimale Einstellung gefunden. Aber was nicht ist, kann ja noch werden.

Glücklicherweise ist UFS2 und ZFS so stabil, das die Panics dem FS nichts ausmachen...
 
Sehr schade. Aber andererseits ist ZFS ja aus gutem Grund in 7.0 noch als experimental gekennzeichnet, sodass eigentlich keiner über eventuellen Datenverlust schreien kann. Wollen wir hoffen, dass das Problem zu 7.1 behoben ist. Wenn man denn auch von ZFS starten kann und es auch sonst komplett unterstützt wird, wäre dies Problem schon deutlich ärgerlicher als aktuell....

Ach ja, die inzwischen finale Version meines Wikiartikels findet sich jetzt unter http://wiki.bsdforen.de/howto/zfs
 
Ich muss leider sagen das ich auf meinem gestern gebauten 7er auch noch immer abstürze habe sobald das System beim copy last bekommt.

Bsp war ein einfaches zfs send receive und ein gleichzeitiger copy job via samba.
 
Habe es mal spassenhalber hiernach versucht, allerdings verstehe ich die Zeile mit dem "legacy" Mode nicht.
und siehe da, hat auch nicht so ganz geklappt.
Kann mir da mal jemand auf die Sprünge helfen.

Greez
 
Ok das waren jetzt sehr viele Infos. Danke, leute!

Mein Resüme (schreibt man das so?): Ich update meinen Laptop und eine WS auf 7.0 sobald der Release da ist, verwende aber weiter UFS2. Auf der WS teste ich dann nebenbei auf kleineren Slices ZFS. Der Server wird erst umgerüstet und upgedatet wenn 7.1 da ist und die Tests auf der WS "zufriedenstellend" waren (sich nicht auf die Stabilität auswirken und Performance nicht wesentlich beeinträchtigen).
 
@ypswes
Im "Legacymode" wird ein Datensatz nicht auf die neue Methode von Zpool vollautomatisch eingehängt, wenn der Pool im System auftaucht. Stattdessen muss es explizit gemountet werden. In dem Howto wird es als ein Hack genutzt um zu verhindern, dass Zpool beim Einhängen des Pools nach dem Kernelboot dir dein / neu mountet und somit - wörtlich - unter dem Arsch wegzieht.
 
Zurück
Oben