Anmerkungen zum ZFS-Tutoria...

Man kann ein Filesystem in zwei Richtungen designen. Das eine Designdogma ist "Datenkorrektheit um jeden Preis", das andere ist "Datenverfügbarkeit um jeden Preis". Man kann nicht beide gleichzeitig erfüllen. Wenn ich "Datenkorrektheit" als oberstes Ziel setze, so muss ich gegebenfalls den Zugriff auf die Daten unterbinden. Wenn ich die Datenverfuegbarkeit an oberste Stelle stelle, muss ich unter umständen auch einmal Daten liefern, die von einem Array mit unklarem Zustand kommen.

ZFS hat sich zum Ziel gesetzt, die Datenvalidität als oberstes Kriterium zu sehen. Das hat ganz praktische Gründe: Datenvalidität sicherzustellen heisst auch, das ich mir gegebenenfalls den Filesystem check auf einem mehrere Petabyte grossen Filesystem sparen kann. Viele Entscheidungen in ZFS sind in Hinblick auf die unschönen Effekte ausgelegt, die 200 TB Filesysteme so mit sich bringen koennen.

Um mal kurz abzuschweifen: Verabschiedet euch von der These, das Daten auf rotierendem Rost sicher sind. Ich finde es teilweise höchst erstaunlich, wie gross das Vertrauen in eine Technik ist, die auf unterster Ebene ein Technik einsetzt, die in ihrer Bezeichnung das Wort "Wahrscheinlichkeit" beinhaltet. Bei der Beschreibung von PRML wird einem doch warm ums Herz. Der weg von der magnetisierten Blase Eisenoxid bis hin in den Speicher ist lang und tierisch gefährlich für ein Bit. Verabschiedet euch insbesondere, das Daten sicher sind, wenn ihr sie auf consumer-grade Elektronik speichert. Zig komponenten und alle vom billigsten Hersteller. Gerade soviel Standard und Testen, als das man nicht sofort damit beim Kunden auf die Nase faellt. IT ist oftmals heute nur noch best-effort computing ... soviel zum allgemeinen IT-Rant ... zurueck zum Tema. ZFS wurde in Hinblick auf diese Entwicklung hin entworfen .

Der Autor des Textes in der c´t hat also mal ein paar Platten gezogen. Das setzt voraus, das man das auch kann und darf. Das geregelte Entfernen von Festplatten kann durchaus etwas problematisch sein : IDE unterstützt beispielsweise Hotplug ueberhaupt nicht (Hotplug heisst ja auch Hotunplug). Damit das funktioniert, muessen eine ganze Reihe von Dinge erfüllt werden. Der Controller muss im AHCI-Modus laufen. Laeuft beispielsweise ein SATA-Port im "IDE emulation mode" kann man zu diesem Zeitpunkt bespielsweise Hotplug vergessen. Die Verbinder mögen vielleicht elektrisch hergeben, das man sie während des Betriebes zieht. Aber die Meldung des Controllers, das da gerade etwas passiert ist, findet nicht statt. Besonders bei SATA gibt es viele Fallen, in die man laufen kann.

Das ist uebrigens einer der Gründe warum SAS selbst bei einfachen Ghetto-JBODS verwendet wird (eSATA ist Desktopstorage ... don´t use it out of home).Es ist dort einfach sauberer und besser standardisiert und implementiert. Damit Hotplug und -unplug wirklich funktioniert, muss das auf der ganzen Kette von der Festplatte bis hin zum Treiber sauber implementiert werden. Es steckt viel Testerei in der Realisierung Storagesystemen und je consumer-grade die Technik ist, deso mehr testen muss man reinstecken, das das ordentlich laeuft. Sind die Standards eingehalten, funktioniert ein Modus fehlerfrei ... uswusf.

Und das ist teilweise eben nicht der Fall, insbesondere wenn man teilweise einfach nur die Ports in einem Mainboard verwendet. Manchmal liegt es sogar einfach nur an den BIOS-Einstellungen, das dann irgendwas sich anders verhaelt als erwartet (IDE emulation anstatt AHCI). Oder manchmal muss man sogar zwangsweise auf IDE-Emulation zwangsweise umschalten, weil ansonsten der Chip nicht sauber funktioniert.Man kann also mit solchen Problem sehr einfach sein IDE-Subsystem in einen Zustand bringen, bei dem man beispielsweise trotz Hotplug die Finger von den Kabeln lassen muss.

Okay ... zurueck zum stehenden zfs status. Was macht ZFS jetzt per default, wenn es Ärger im IDE-Subsystem gibt? Es geht davon aus, das jeder weitere Zugriff auf das System potentiell den Inhalt des Filesystem schädigen kann und unterbindet daher jeden Zugriff darauf, bis entweder die fehlenden Devices wieder anschlossen worden sind beziehungsweise diese ausgetauscht worden sind (z.B. automatisch durch die Fault Management Architecture)

Jetzt werden einige Leute sagen, das ihnen die Datenkorrektheit egal ist und auf alle Faelle auch bei unschoenen Betriebszuständen weiter Daten zumindestens gelesen werden sollen. Nun, man kann dieses Verhalten ändern. Dazu gibt es das failmode property eines Storage pools. In der man page zu zpool steht zum Thema des failmode:

failmode=wait | continue | panic
Controls the system behavior in the event of catastrophic pool failure. This condition is typically a result of a loss of connectivity to the underlying storage device(s) or a failure of all devices within the pool. The behavior of such an event is determined as follows:

• wait
  Blocks all I/O access until the device connectivity is recovered and the errors are cleared. This is the default behavior.
• continue
  returns EIO to any new write I/O requests but allows reads to any of the remaining healthy devices. Any write requests that have yet to be committed to disk would be blocked.
• panic
  Prints out a message to the console and generates a system crash dump.

Warum funktionieren aber nun andere Filesysteme ohne solche Spirenzchen. Es ist das allgemeine Designdogma was hier anders ist. ZFS misstraut der Hardware und die Defaulteinstellungen sind Zeichen dieses Misstrauens. Im Grunde misstraut es auch den Treibern in Solaris. Um die Datenvalidität zu sichern, geht ZFS soweit den Zugriff auf die Daten durch Blocking zu verweigern, bis das System wieder in einem definierten Zustand ist, von dem ausgehend man weiterarbeiten kann.

Linux, ext2/ext3, NTFS, Windows gehen von einem anderen Modell aus, reagieren anders, solange da etwas ankommt, wird ausgeliefert. Ob das allerdings bei einem Filesystem, das nicht ueber Checksummen verfügt, um die Datenvalidität sicherzustellen, eine wirklich kluge Idee ist, mag jeder für sich selbst entscheiden.

Kabelziehen ist sowieso noch ein recht einfacher Fehler. Die interessante Frage ist doch, ob man einem Festplattensubsystem beim Lesen vertrauen kann, bei dem gerade mal eine Platte ohne Mitteilung verschwunden ist. Die Entscheidung, dieses Risiko einzugehen, sollte eine bewusste Entscheidung sein, ergo die oben gewählte Defaulteinstellung.

Achja ... ein Wort noch zu den Tests, die Festplattenausfälle durch das Ziehen von Kabeln simulieren wollen: Ihr testet damit abfallende Kabel und den Effekt von Benutzern, die wild einfach mal so Kabel ziehen, aber keine defekte Festplatte. Wer allerdings ein Problem mit abfallenden Kabeln hat, sollte sich ueberlegen, ob er nicht mal anständige Kabel einsetzt, so mit Verschraubungen oder vernuenftigen Arretierungen.