[linux-l] Dateisystem-Konsistenz

[olafBuddenhagen at gmx.net]

Hallo,

On Mon, Feb 09, 2009 at 03:14:48PM +1100, Peter Ross wrote:
> On Sun, 8 Feb 2009, olafBuddenhagen at gmx.net wrote:

> > Die Atomic Updates sind nur ein (sinnvoller) Ersatz fuer
> > Journalling. Sie machen *nicht* den Konsistenzcheck ueberfluessig,
> > der ja bei Journaling-Filesystems dazu dient, Schaden schaden zu
> > begrenzen, wo Journaling nicht greift -- bei Bugs in Hardware oder
> > Software.
> 
> http://www.tech-recipes.com/rx/1405/zfs-how-to-fsck-or-check-filesystem-integrity-with-scrub/
> --------------------------------------------------------------------------
> How do you use fsck with a ZFS filesystem? You don't. ZFS filesystems
> are always clean so even in the worst case of a power outage bringing
> a system down, you'll never be asked to give the root password for
> system maintenance again. With ZFS, data are always consistent on
> disk. For you worriers, there is a command you can use to make sure
> everything is okay with your filesystems.
> 
> Unlike of the fsck command which had to be run on an unmounted
> filesystem (read: downtime), the zpool command has a scrub option
> which works on a mounted, living filesystem. When run, the command
> checks all data in the pool for checksum consistency. On redundant
> systems (raidz or mirror), inconsistencies will be repaired.
> --------------------------------------------------------------------------

Dass der Check online geht, ist zweifelsfrei sehr praktisch -- aber kein
Grund es deswegen anders zu nennen.

> Da ZFS alles Daten mit Checksummen schreibt und liest, werden
> Lesefehler sofort bemerkt, und im Falle von Mirrors oder raidz ist
> genügend Information, diesen Fehler auch zu _beheben_, anstatt
> anzuzeigen.

Sofort wenn die beschaedigten Daten gelesen werden... Was unter
Umstaenden zu spaet sein kann fuer wirksame Reperaturmasznahmen. Ein
regelmaesziger Check ist nach wie vor sinnvoll.

> Während es bei billiger Desktophardware schon vorstellbar ist, daß
> Reordering der Schreibmethode und plötzlicher Stromausfall zu
> korrupten Daten auf der Platte führen, (und man kann in der Regel
> Controller-Caching abschalten),
> 
> Bei Serverhardware, die den Namen verdient, ist eine Batterie im
> Spiel, die dem Controller genügend Zeit gibt, alles noch auf Platte zu
> bannen.
> 
> Eine Dell PERC-Karte z.B. prüft die Batterie fortlaufend und schaltet
> Caching automatisch ab, wenn diese wiedergeladen werden muß. Wenn man
> das genau wissen möchte (muß - um im Falle eines dauerhaften
> Batterieschadens und Abschalten des Caches Performance-Einbußen zu
> erkennen) hilft OpenManage, das zu sehen bzw. Alarm zu schlagen.
> Nagios z.B. hat Plugins, die den Status prüfen.
> 
> UFS softupdates ordnen die Daten vor dem Schreiben, wenn dann nicht
> billiger Schund dazwischen liegt, ist das Filesystem auch bei
> Stromausfall brauchbar - ein automatischer Filesystemcheck im
> Background während des Rebotes korrigiert im Hintergrund, wenn nötig
> (z.B. wenn freigewordene Blöcke noch nicht in der Freiliste sind).
> Softupdates garantieren aber keine vollständigen Datenerhalt beim
> Schreiben und Stromausfall, lediglich Konsistenz des Filesystems.
> Dagegen hilft in Grenzen gjournal auf Blockebene (ein Cache, der
> Schreiben auf das Blockdevice protokolliert, bevor es schreibt).
> Ansonsten o.g. Severhardware.

Thema verfehlt, sechs.

Mal davon abgesehen, dass die meisten Leute sich nun mal mit billiger
Hardware rumschlagen muessen, und Dateisystemchecks schon deshalb
unabdingbar sind: Ich habe ausdruecklich *nicht* von Stromausfall
gesprochen. Der Fall ist einfach -- ob durch Journalling, Logging,
Atomic Updates, oder Snapshotting: Jedes Dateisystem, was in den letzten
zehn Jahren oder so entwickelt wurde, ist *theoretisch* vor
Inkonsistenzen sicher.

Aber es ist nun mal nicht alles Theorie. Auch bei teurer Hardware sind
Schreib- und Lesefehler durchaus nicht ausgeschlossen; und selbst bei
perfekter Hardware koennen immer noch Bugs in der Software zu kaputten
Dateisystemen fuehren. Checks muessen also sein. (Wobei Checksummen und
redundante Metadaten dabei natuerlich sehr hilfreich sind...)

> Ich habe seit etlichen Jahren keinerlei Filesystemprobleme unter
> FreeBSD, selbst bei Desktops,
> 
> während ich z.B. im letzten Jahr viermal ernsthafte Probleme mit ext3
> hatte. Ein Rechner, eine virtuelle VMWare-Maschine auf einem
> SAN-server (welcher keinerlei Probleme anzeigte), war so kaputt, daß
> die Hälfte von /usr/bin verschwunden war etc.

Ich wuerde es sehr begrueszen, wenn Du das daemliche trollen
unterlaesst, waehrend ich versuche eine vernuenftige Diskussion zu
fuehren, danke.

-Olaf-