Wie stabil ist/wird ZFS unter FreeBSD 8.2 und 9.0?
Kann man ZFS unter FreeBSD >=8.2 gefahrlos als rootfs einsetzen?
Vertragen sich ZFS und gmirror im produktiven Einsatz?
Ist ZFS immernoch RAMhungrig? Wieviel RAM wird empfohlen?
Irgendwelche Quirks beim ZFS-Einsatz zu beachten?
FreeBSD und ZFS
-
Joe User
- Project Manager
- Posts: 11190
- Joined: 2003-02-27 01:00
- Location: Hamburg
FreeBSD und ZFS
PayPal.Me/JoeUser ● FreeBSD Remote Installation
Wings for Life ● Wings for Life World Run
„If there’s more than one possible outcome of a job or task, and one
of those outcomes will result in disaster or an undesirable consequence,
then somebody will do it that way.“ -- Edward Aloysius Murphy Jr.
Wings for Life ● Wings for Life World Run
„If there’s more than one possible outcome of a job or task, and one
of those outcomes will result in disaster or an undesirable consequence,
then somebody will do it that way.“ -- Edward Aloysius Murphy Jr.
-
rudelgurke
- Posts: 410
- Joined: 2008-03-12 05:36
Re: FreeBSD und ZFS
Gmirror wird man mit ZFS nicht mehr brauchen. Allerdings hat zumindest ein lokaler Test hier gezeigt dass die Performance leidet wenn weniger als ca. 2 GB RAM vorhanden sind.
Glaube so um die 2-4 GB werden empfohlen, sonst hat man mehr Probleme als Vorteile.
Und booten von / als ZFS soll funktionieren, dazu gibt es ein Howto im FreeBSD Wiki. Allerdings, bin vielleicht zu konservativ, gerade /rescue möchte ich gern als UFS haben falls es zu Problemen kommt.
Wie gesagt - bin vielleicht etwas konservativ aber ich warte noch einige Zeit bis es auf die Produktionssysteme kommt.
Achso - Testumgebung war ein 8.1, 8.2 RC und ein 9 Current (Stand Januar 2011), jeweils auf einem Core 2 Duo mit 1 GB RAM, einem Phenom X4 mit 6 GB RAM - jeweils SATA Platten.
Gerade die Kiste mit 1 GB RAM hatte massive Probleme bin hin zur Kernel Panic, kmem_size war zu niedrig angesetzt.
Vielleicht hat jemand anders bessere Erfahrungen gemacht, derzeit eher gemischte Gefühle und UFS2 + Gmirror sind auch nicht so schlecht.
Nachtrag: Auf dem Phenom lief es besser. Peformance Probleme gab es keine soweit, schaut man in die Mailing Liste muss man wohl, je nach Einsatz und Hardware, hier und da etwas drehen bis es optimal läuft.
Persönlich - nur persönlich - mit weniger als 4 GB RAM würde ich UFS + Geom / Gmirror etc. bevorzugen.
Glaube so um die 2-4 GB werden empfohlen, sonst hat man mehr Probleme als Vorteile.
Und booten von / als ZFS soll funktionieren, dazu gibt es ein Howto im FreeBSD Wiki. Allerdings, bin vielleicht zu konservativ, gerade /rescue möchte ich gern als UFS haben falls es zu Problemen kommt.
Wie gesagt - bin vielleicht etwas konservativ aber ich warte noch einige Zeit bis es auf die Produktionssysteme kommt.
Achso - Testumgebung war ein 8.1, 8.2 RC und ein 9 Current (Stand Januar 2011), jeweils auf einem Core 2 Duo mit 1 GB RAM, einem Phenom X4 mit 6 GB RAM - jeweils SATA Platten.
Gerade die Kiste mit 1 GB RAM hatte massive Probleme bin hin zur Kernel Panic, kmem_size war zu niedrig angesetzt.
Vielleicht hat jemand anders bessere Erfahrungen gemacht, derzeit eher gemischte Gefühle und UFS2 + Gmirror sind auch nicht so schlecht.
Nachtrag: Auf dem Phenom lief es besser. Peformance Probleme gab es keine soweit, schaut man in die Mailing Liste muss man wohl, je nach Einsatz und Hardware, hier und da etwas drehen bis es optimal läuft.
Persönlich - nur persönlich - mit weniger als 4 GB RAM würde ich UFS + Geom / Gmirror etc. bevorzugen.
Last edited by rudelgurke on 2011-02-02 23:08, edited 1 time in total.
-
daemotron
- Administrator
- Posts: 2643
- Joined: 2004-01-21 17:44
Re: FreeBSD und ZFS
8.2 wird dieselbe Version (v14) wie 8.1 enthalten - Martin Matuska hat aber aus Pawels Portierung von v28 (gegen HEAD) einen Patch für STABLE gebaut (siehe http://lists.freebsd.org/pipermail/free ... 60626.html). Es bestehen also Chancen, dass in 8.3 dann die neue Version zum Zuge kommt.
Wenn also keine anderen Subsysteme vergurkt wurden, ist ZFS unter 8.2 genauso gut und stabil wie unter 8.1. Ich habe einen v14er Pool seit geraumer Zeit im produktiven Einsatz (seit ca. einem Jahr), bislang ohne jedes Problem. Ich hatte neulich ja drüber gebloggt; die Leseperformance ist wirklich gut (auch bei random reads), während die Schreibperformance in etwa mit UFS vergleichbar ist (nur bei Rewrites bricht sie bei mir komplett ein). Von der Stabilität und Datenintegrität her ist auf jeden Fall alles in bester Ordnung.
Was den RAM-Hunger betrifft, ist das hauptsächlich eine Frage des Tunings. Man kann ZFS so runterschrauben, dass es auch auf einer Kiste mit nur einem GB RAM zufriedenstellend läuft - aber dann mit äußerst mieser Performance. In meiner Maschine sind 8 GB RAM verbaut, ZFS verbrät davon so zwischen 400 und 800 MB. Solange man eine amd64-Installation hat, gibt's auch keine Probleme mit dem Kernel memory address range - bei i386 ist der für ZFS mit 300 MB "etwas" zu knapp ausgelegt (kann man aber notfalls umbiegen).
Zum Thema ZFS und gmirror - wie genau meinst Du das? Willst Du ZFS auf ein gm-Device stapeln? Oder meinst Du nur parallel ein Zpool und ein gm-Array im selben System? Bei mir habe ich zwei Slices zu einem gm-Device verbandelt, und zwei weitere Slices derselben Platten bilden einen Zpool vom Typ mirror. Das verträgt sich wunderbar. Stapeln würde ich GEOM und ZFS hingegen nicht unbedingt. Man kann zwar GEOM auf ZFS Raw Devices loslassen, verliert aber dabei natürlich viele Vorteile von ZFS (Snapshots, dynamische Quotierung, etc.). Umgekehrt kann man auch GEOM-Devices an einen Zpool verfüttern. Technisch gesehen geht das, und solange man stabile GEOM-Teile (wie gmirror oder geli) verwendet, läuft das auch - aber ziemlich lahm. Ist irgendwie logisch, je mehr Abstraktionsschichten da übereinander gestapelt vor sich hinwerkeln, durch umso mehr verschiedene Subsysteme wird ein Write oder Read gefleischwolft, bevor die Platte tatsächlich was tun darf.
Zum letzten Punkt - ZFS als Root-Dateisystem würde ich momentan nicht einsetzen. Technisch gesehen geht es natürlich, aber so richtig viel Sinn macht es IMHO nicht. Ich habe den für's booten lebenswichtigen Part lieber auf bewährter Technik, damit ich das System auch bei ZFS-Problemen noch booten kann - Rettungswerkzeuge gibt's nämlich noch keine vernünftigen. Eine OpenSolaris-LiveCD könnte helfen, aber bisher ist es mir nicht gelungen, einen Zpool mit einem anderen OS zu importieren als mit dem, auf dem er erstellt wurde.
Wirklich sinnvoll ist ZFS IMHO nur in einem Setup mit einer (oder zwei per gmirror gespiegelten) kleinen Systemplatte(n) und >=3 Datenplatten, die den Zpool bilden. Alles drunter kann man genauso gut und performant mit GEOM und UFS2 lösen, und das bei deutlich geringerem Ressourceneinsatz.
Wenn also keine anderen Subsysteme vergurkt wurden, ist ZFS unter 8.2 genauso gut und stabil wie unter 8.1. Ich habe einen v14er Pool seit geraumer Zeit im produktiven Einsatz (seit ca. einem Jahr), bislang ohne jedes Problem. Ich hatte neulich ja drüber gebloggt; die Leseperformance ist wirklich gut (auch bei random reads), während die Schreibperformance in etwa mit UFS vergleichbar ist (nur bei Rewrites bricht sie bei mir komplett ein). Von der Stabilität und Datenintegrität her ist auf jeden Fall alles in bester Ordnung.
Was den RAM-Hunger betrifft, ist das hauptsächlich eine Frage des Tunings. Man kann ZFS so runterschrauben, dass es auch auf einer Kiste mit nur einem GB RAM zufriedenstellend läuft - aber dann mit äußerst mieser Performance. In meiner Maschine sind 8 GB RAM verbaut, ZFS verbrät davon so zwischen 400 und 800 MB. Solange man eine amd64-Installation hat, gibt's auch keine Probleme mit dem Kernel memory address range - bei i386 ist der für ZFS mit 300 MB "etwas" zu knapp ausgelegt (kann man aber notfalls umbiegen).
Zum Thema ZFS und gmirror - wie genau meinst Du das? Willst Du ZFS auf ein gm-Device stapeln? Oder meinst Du nur parallel ein Zpool und ein gm-Array im selben System? Bei mir habe ich zwei Slices zu einem gm-Device verbandelt, und zwei weitere Slices derselben Platten bilden einen Zpool vom Typ mirror. Das verträgt sich wunderbar. Stapeln würde ich GEOM und ZFS hingegen nicht unbedingt. Man kann zwar GEOM auf ZFS Raw Devices loslassen, verliert aber dabei natürlich viele Vorteile von ZFS (Snapshots, dynamische Quotierung, etc.). Umgekehrt kann man auch GEOM-Devices an einen Zpool verfüttern. Technisch gesehen geht das, und solange man stabile GEOM-Teile (wie gmirror oder geli) verwendet, läuft das auch - aber ziemlich lahm. Ist irgendwie logisch, je mehr Abstraktionsschichten da übereinander gestapelt vor sich hinwerkeln, durch umso mehr verschiedene Subsysteme wird ein Write oder Read gefleischwolft, bevor die Platte tatsächlich was tun darf.
Zum letzten Punkt - ZFS als Root-Dateisystem würde ich momentan nicht einsetzen. Technisch gesehen geht es natürlich, aber so richtig viel Sinn macht es IMHO nicht. Ich habe den für's booten lebenswichtigen Part lieber auf bewährter Technik, damit ich das System auch bei ZFS-Problemen noch booten kann - Rettungswerkzeuge gibt's nämlich noch keine vernünftigen. Eine OpenSolaris-LiveCD könnte helfen, aber bisher ist es mir nicht gelungen, einen Zpool mit einem anderen OS zu importieren als mit dem, auf dem er erstellt wurde.
Wirklich sinnvoll ist ZFS IMHO nur in einem Setup mit einer (oder zwei per gmirror gespiegelten) kleinen Systemplatte(n) und >=3 Datenplatten, die den Zpool bilden. Alles drunter kann man genauso gut und performant mit GEOM und UFS2 lösen, und das bei deutlich geringerem Ressourceneinsatz.
Last edited by daemotron on 2011-02-02 23:12, edited 1 time in total.
“Some humans would do anything to see if it was possible to do it. If you put a large switch in some cave somewhere, with a sign on it saying 'End-of-the-World Switch. PLEASE DO NOT TOUCH', the paint wouldn't even have time to dry.” — Terry Pratchett, Thief of Time
-
Joe User
- Project Manager
- Posts: 11190
- Joined: 2003-02-27 01:00
- Location: Hamburg
Re: FreeBSD und ZFS
Ich hatte ursprünglich daran gedacht ein gmirror-RAID1 (gm0) über beide SATAII-Platten (ad4+ad6) anzulegen und gm0 dann mit ZFS-Pools zu "partitionieren". Wenn es aber keine Rescuetools gibt, dann kommt ZFS ohnehin maximal für die Nutzdaten und/oder Jails in Frage und bringt letztendlich keinen echten Mehrwert mehr, zumindest noch nicht.
Danke für die hilfreichen Antworten, bleibe dann bei gmirror+UFS2.
Danke für die hilfreichen Antworten, bleibe dann bei gmirror+UFS2.
PayPal.Me/JoeUser ● FreeBSD Remote Installation
Wings for Life ● Wings for Life World Run
„If there’s more than one possible outcome of a job or task, and one
of those outcomes will result in disaster or an undesirable consequence,
then somebody will do it that way.“ -- Edward Aloysius Murphy Jr.
Wings for Life ● Wings for Life World Run
„If there’s more than one possible outcome of a job or task, and one
of those outcomes will result in disaster or an undesirable consequence,
then somebody will do it that way.“ -- Edward Aloysius Murphy Jr.
-
daemotron
- Administrator
- Posts: 2643
- Joined: 2004-01-21 17:44
Re: FreeBSD und ZFS
Das funktioniert ohnehin nicht. Einem Zpool kann man nicht Teile eines Device verfüttern - da müsste man schon partitionieren (also Slices auf dem gm0-Device anlegen). Aus den einzelnen Slices ließen sich dann wieder Zpools bauen. Wenn man aber sowieso slicen muss, kann man auf gmirror auch gleich ganz verzichten und aus den Einzel-Slices der jeweiligen Platten gespiegelte Zpools bauen.
Also um noch mal mit den Device-Namen von oben zu verdeutlichen, hast Du folgende Optionen:
So, und zum Abschluss noch der Schocker: das langsamste mögliche Setup:
gm0 aus ad4 und ad6. Auf einer Slice auf gm0 (sagen wir mal, auf gm0s2) noch geli draufknallen, als Algorithmus Blowfish wählen. Auf gm0s2.eli Disklabel anlegen; gm0s2.elia mit UFS formatieren. Darauf dann 4 Dateien anlegen und die zu einem RAIDZ2-Zpool zusammenkleben. Und dann mit iozone feststellen, dass eine mechanische Schreibmaschine einen höheren Durchsatz hat :ymparty:
Also um noch mal mit den Device-Namen von oben zu verdeutlichen, hast Du folgende Optionen:
- Ein Zpool vom Typ mirror aus ad4 und ad6, der dann allerdings auch als Root dienen muss
- Mehrere Zpools vom Typ mirror aus einzelnen Slices; kombinierbar mit gmirror (falls UFS für's RootFS eingesetzt werden soll). Beispiel: gm0 aus ad4s1 und ad6s1, zpool1 (mirror) aus ad4s2 und ad6s2, zpool2 (mirror) aus ad4s3 und ad6s3, etc.
- Alternative zum vorhergenden Setup: zpool (raidz2) aus ad4s2, ad4s3, ad6s2, ad6s3.
So, und zum Abschluss noch der Schocker: das langsamste mögliche Setup:
gm0 aus ad4 und ad6. Auf einer Slice auf gm0 (sagen wir mal, auf gm0s2) noch geli draufknallen, als Algorithmus Blowfish wählen. Auf gm0s2.eli Disklabel anlegen; gm0s2.elia mit UFS formatieren. Darauf dann 4 Dateien anlegen und die zu einem RAIDZ2-Zpool zusammenkleben. Und dann mit iozone feststellen, dass eine mechanische Schreibmaschine einen höheren Durchsatz hat :ymparty:
“Some humans would do anything to see if it was possible to do it. If you put a large switch in some cave somewhere, with a sign on it saying 'End-of-the-World Switch. PLEASE DO NOT TOUCH', the paint wouldn't even have time to dry.” — Terry Pratchett, Thief of Time
-
Joe User
- Project Manager
- Posts: 11190
- Joined: 2003-02-27 01:00
- Location: Hamburg
Re: FreeBSD und ZFS
Danke für die recht informative Aufklärung. Damit (und dem obigen Patch) steht dann endgültig fest, dass ich ZFS frühestens in v30+ verwenden möchte. Das wird dann wohl erst ab FreeBSD 9.2 der Fall sein, wenn nicht so gar erst ab FreeBSD 10.x.
[x] Haben will 8)daemotron wrote:Und dann mit iozone feststellen, dass eine mechanische Schreibmaschine einen höheren Durchsatz hat :ymparty:
PayPal.Me/JoeUser ● FreeBSD Remote Installation
Wings for Life ● Wings for Life World Run
„If there’s more than one possible outcome of a job or task, and one
of those outcomes will result in disaster or an undesirable consequence,
then somebody will do it that way.“ -- Edward Aloysius Murphy Jr.
Wings for Life ● Wings for Life World Run
„If there’s more than one possible outcome of a job or task, and one
of those outcomes will result in disaster or an undesirable consequence,
then somebody will do it that way.“ -- Edward Aloysius Murphy Jr.