Ich habe FreeBSD 8.0 und anschließend 8.0-Stable-Snapshot vom Februar 2010 verwendet, um mit ZFS für ein paar Monate zu experimentieren. Das System verfügt über ein paar unabhängige RAID-1-Pools mit 4 Festplatten. Auf den ersten Blick schien das Ganze mehr oder weniger perfekt zu laufen, obwohl ich auf einige zunehmend beunruhigende Probleme gestoßen bin. Ich denke, dass es unter bestimmten Umständen und Konfigurationen ratsam ist, diese Einstellung zu vermeiden. Mein erstes Problem ist nicht unbedingt die Stabilität / Funktionalität nicht von FreeBSD / ZFS selbst, sondern die Zuverlässigkeit und Funktionalität bestimmter Gerätetreiber und Laufwerke unter FreeBSD. Ich fand heraus, dass der standardmäßige ata / ide-Treiber den Controller, den ich verwende, nicht unterstützte, der siis-Silizium-Image-Speichertreiber jedoch über die erforderliche Port-Multiplikator-SATA-Unterstützung verfügte, damit die Laufwerke mit FreeBSD 8 funktionieren. Bei genauerer Betrachtung ist der Treibercode jedoch nicht wirklich produktionsbereit, IMHO - er hat die erste auf die Disc bezogene weiche Fehler- / Zeitüberschreitungs- / Wiederholungsbedingung, die dazu geführt hat, dass ein Laufwerk im Array etwas verzögert hat, nicht wie ein paar Dutzend ausgeführt Sekunden. Ich weiß nicht genau, was passiert ist, aber es dauerte ungefähr eine Minute, bis das Array einen Timeout, Reset und Wiederherstellungsvorgang ausgeführt hat. In dieser Zeit ging jedes einzelne Laufwerk im Array aus dem Betriebszustand 'verloren' und führte zu einem nicht behebbaren Datenfehler auf der höheren Dateisystemebene. AFAICT Sogar der Betreuer des SIIS-Treibers sagt, dass die Timeout- / Reset-Behandlung des Treibers noch nicht vollständig abgeschlossen / robust / optimiert ist. Fair genug, aber der Punkt ist, egal wie gut das OS oder ZFS ist, Wenn Sie über ein unzuverlässiges Laufwerk oder Controller oder einen unzuverlässigen Treiber verfügen, kann dies sicherlich den gesamten Betrieb so stark ruinieren, dass es trotz ZFS zu schwerwiegenden Fehlern und Datenverlust kommt. SMART-Diagnoseanforderungen scheinen auch nicht mit diesem speziellen Controller-Treiber zu funktionieren. Was hat den Fehler verursacht? Flockige Seagate-Laufwerke / Firmware? Ich weiß es nicht, aber mit einem Laufwerkfehler kann das gesamte Array "ausfallen", obwohl der RAIDZ den ganzen Punkt der Zuverlässigkeit eines RAIDZ zerstört. Das Verhalten nach dem Problem mit zpool scrup / zpool status et. al. war auch etwas verdächtig, und es ist nicht wirklich klar, ob der Diagnose- / Wiederherstellungsprozess auf ZFS / ZPOOL-Ebene ordnungsgemäß funktioniert hat. sicherlich habe ich einige gemischte Meldungen über Fehlerzustände und Fehlerbeseitigung erhalten. al. Die Fehleranzeigen verschwanden nach einem Neustart trotz des fehlenden expliziten Befehls zpool clear. Vielleicht ist das beabsichtigt, aber wenn dies der Fall ist, wird dies von der Ausgabe des Zpool-Status nicht vorgeschlagen.
Es könnte ernsthaft sein, dass etwas während des Betriebs nach einigen Tagen Betriebsbereitschaft versehentlich schiefgegangen ist, wobei große Teile des Arrays, die mehrere Dateisysteme (ZFS) enthalten, gerade "verschwunden" sind, weil sie in (ls) und beim normalen E / A-Zugriff aufgeführt sind . IIRC df -h, ls usw. meldete die Dateisysteme nicht als vorhanden, während der Status von zpool list / zpool weiterhin die erwartete Menge an verbrauchtem Speicher im Pool angab, jedoch nicht von allen aufgeführten gemounteten oder nicht gemountete Dateisysteme. / var / log / messages enthielt keine Fehlermeldung über die Fehlermeldung, und die Vorgänge wurden vor diesem Problem völlig normal ausgeführt. zpool list / zpool status zeigte keine Probleme mit dem Pool an. Ein zfs-Unmount -a ist fehlgeschlagen, ohne dass es einen offensichtlichen Grund für die interaktive Verwendung gab, bevor das letzte der gemounteten zfs-Dateisysteme aufgehoben wurde. Neustarten und erneutes Überprüfen von / var / log / messages, zpool-Status, zpool-Liste war kein Problem. Die zuvor fehlenden Dateisysteme wurden tatsächlich erneut mounten, wenn sie dazu aufgefordert wurden, manuell nachzuschlagen, und hatten anscheinend den richtigen Inhalt. Nach etwa einer Minute, in der verschiedene zfs-Systeme im Pool eingebunden wurden, wurde festgestellt, dass einige unerwartet wieder verschwunden waren. Es ist möglich, dass ich '
Zugegeben, ich führe den stabilen Snapshot Feb'10 aus, der NICHT für die Verwendung in der Produktion empfohlen wird. Allerdings wurden seit der Veröffentlichung von 8.0 einige relativ bemerkenswerte Korrekturen an bekannten ZFS / Speicherproblemen an den stabilen Zweig übergeben in Bezug auf Zuverlässigkeit / Funktionen aufgrund dieser Probleme für manche Menschen unbefriedigend.
Trotzdem haben nur ein paar Wochen relativ leichter Tests zu potenziell katastrophalen Zuverlässigkeits- / Funktionsproblemen geführt, die nicht alle mit den besonderen Mängeln der Speicherlaufwerke / Controller / Treiber zu tun haben, die ich vorsichtig beim Vertrauen auf FBSD 8.0 habe + ZFS für den Produktions- / Zuverlässigkeitsbereich ohne eine sehr sorgfältig kontrollierte Hardware- und Softwarekonfiguration und Offline-Backup-Strategie.
OpenSolaris ist im Moment ohnehin ein NoGo, selbst wenn Sie es ausführen wollten - da es ernsthafte Probleme mit der zfs-Deduplizierung gibt, ist das ziemlich unbrauchbar, und dies und andere Probleme scheinen zu einer Empfehlung zu führen, auf die gewartet werden muss ein paar weitere Patch-Versionen, die veröffentlicht werden sollen, bevor OpenSolaris + ZFS insbesondere mit einem Dedup-System vertraut wird. B135 / B136 scheinen zusammen mit der wichtigen OS-Version 2010.03 ohne Erklärung einfach zu fehlen. Einige sagen, Oracle sei nur knapp über einen Zeitplan-Slippage informiert, die erwarteten Codes werden jedoch verspätet veröffentlicht, während andere sich fragen, ob der vollständige Satz erwarteter Features in der Entwicklung von Sun als zukünftige Open-Source-Versionen erscheinen wird von Oracle angesichts des Übergangs in Besitz / Führung / Management.
IMHO würde ich nur mit Spiegeln bleiben und nur mit sehr gut überprüften / stabilen Speichercontrollertreibern und Laufwerksmodellen für optimale ZFS-Zuverlässigkeit unter FreeBSD 8, und ich würde wahrscheinlich auch auf 8.1 warten.