[linux-l] Dateisystem-Konsistenz (was: [OT] größtes RAID: bestes FS?)

[Peter Ross]

Hi Olaf,

On Sun, 8 Feb 2009, olafBuddenhagen at gmx.net wrote:

> On Fri, Feb 06, 2009 at 10:34:24AM +1100, Peter Ross wrote:
>
> > ZFS (und btrfs) schreiben zunächst alles, bevor im letzten Schritt die
> > Metadaten auf den neuen Inhalt verweisen. Dadurch ist das Filesystem
> > zu jedem Zeitpunkt konsistent.
>
> Schoen waer's...
>
> 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.
--------------------------------------------------------------------------
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.

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.

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.

Online-Datensicherheit ist eine Kombination aus Filesystem-Grundlagen,
Aufwand zur Redundanz (Raids, Mirrors, zpools etc.+
Service/Server-Failover) und vernünftiger Hardware. Offline kommt dann
noch Backup dazu.

Wenn eine dieser Komponenten streikt, kann man in Grenzen mit den anderen
ausgleichen. Das erhöht aber die Komplexität und letztendlich die Chance,
daß die Komponente "Mensch" durch Fehleinschätzung, Design- und
Kunstfehler versagt.

Gruß
Peter

This email, including attachments, is intended only for the addressee and may be confidential, privileged and subject to copyright. If you have received this email in error, please advise the sender and delete it. If you are not the intended recipient of this email, you must not communicate to others content that is confidential or subject to copyright, unless you have the consent of the content owner.