ext4: Metadata checksums

Achtung! Dieser Artikel ist älter als ein Jahr. Der Inhalt ist möglicherweise nicht mehr aktuell!

Vorgeschichte

Seit kurzem hatte ich Kontakt wegen meinem Tor Experiment bei Server4You mit einem Mitarbeiter bei SAP. Seitdem schreiben wir hin und wieder ein paar Mails hin und her. Heute war mein neues NAS bzw. neuer Homeserver Thema.

Ich habe mich ja gegen FreeBSD/FreeNAS und das ZFS entschieden. Ich habe das klassische Software RAID 5 und dem ext4 Dateisystem gewählt, weil ich glaubte mich besser damit auszukennen.

In der Mail wies er mich darauf hin, dass ext4 keine Checksummen bildet. Das ist eigentlich ziemlich wichtig, da bei unbemerkten Bitfehler zwar die angezeigte Fehlerrate sehr klein ist, aber im Falle eines Ausfalles und des daraus resultierenden Recovery Prozesses schwerwiegende Fehler auftreten könne – bis hin zum fast vollständigen Datenverlusts.

Den ganzen Abend hat mich das eigentlich gequält, da ich ja durch das RAID eigentlich Datensicherheit und -integrität erhalten wollte. ZFS war mit vor FreeNAS nie untergekommen und man liest auch sehr selten was darüber. Fakt ist: ZFS hat sowas schon fest integriert.

Ext4 wird auch von unzähligen Firmen verwendet. „Machen die sich denn keine Gedanken über sowas?“, habe ich mich gefragt und mich auf die Suche gemacht. Ziemlich schnell bin ich fündig geworden. Das Zauberwort heißt „Metadata Checksums“.

Was bedeutet „Metadata Checksums“

Ich bin oft auf diese Wiki-Seite über das Thema auf kernel.org verwiesen worden. Kurz Zusammengefasst: Jede Information vom Dateisystem wird ein crc32c Hash generiert und verglichen. Wenn ich nun meine Dateien speichern will, dann wird zuerst ein Hash von den Metadaten gebildet, physikalisch geschrieben und wieder ein Hash gebildet und verglichen.

Stimmt alles geht’s normal weiter, wenn der Vergleich fehlschlägt weis ich nicht genau was passiert. Ich nehme an, es wird ein toter Block erkannt und gespeichert sowie die Datei an anderer Stelle geschrieben.

Anforderungen

an das Betriebssystems

Laut Wiki-Artikel hat man einige Anforderungen:

Das Problem ist, dass in Ubuntu 14.10 e2fsprogs in der Version 1.42 vorhanden ist. Mit dieser Version funktioniert das leider nicht. Es gibt auch keine offizielles PPA, aber eine (ich nenne es mal) User Driven Kompilat als PPA. An dieser Stelle möchte ich mal meinen Dank an den Autor kund tun und anmerken, dass ich froh bin, dass ich Ubuntu Server als OS gewählt habe – Wieder mal Schwein gehabt :-)

an die Programme

Ich habe noch nie in meinem Leben ein PPA zu APT hinzugefügt. Eigentlich ist es aber ziemlich einfach. Als root folgende Befehle in das Terminal:

add-apt-repository ppa:daniel-mehrmann/admin
apt-get update
apt-get upgrade

Es sollten sich das Programme e2fsprogs upgraden.

Das Dateisystem erweitern

Das coole ist, das man das Dateisystem nicht neu erstellen muss. Ein vorhandenes Dateisystem kann erweitert werden. Zuerst beendet man sämtliche Dienste, die auf das Dateisystem zugreifen und unmounted das Dateisystem.

Da ich hier ein zweites, unabhängiges Dateisystem ändere brauche ich keine Live-CD dafür.

Mein Aufbau

Bei mir ist das RAID 5 über /dev/md0 erreichbar. Auf diesem RAID liegt aber noch LUKS, damit bei einem eventuellem Diebstahl (*hust* oder einer anderen Aktivität, bei der man unfreiwillig seine Festplatten verliert. *hust*) nichts böses passieren kann.

_/dev/md0_ wird mit cryptsetup nach _/dev/mapper/md0crypt „gemountet“. Erst dann kommt der normale mount nach /mnt. Jetzt könnte ich auf das „richtige“ Dateisystem zugreifen. Da ich es aber im Kern ändern will muss ich es unmounten: umount /mnt

Nun habe ich über die Device-Datei /dev/mapper/md0_crypt Zugriff von Hinten auf das Dateisystem.

Die eigentliche Erweiterung

Nun ist es endlich soweit. Die eigentliche Erweiterung kann stattfinden.

Mit tune2fs führe ich die Änderungen durch:

tune2fs -O metadata_csum /dev/mapper/md0_crypt

Dies kann eine weile dauern. Bei meinen 3 TB Daten dauerte es ca. 10 Minuten. Das keine Ausgabe kommt ist normal – Kaffe und Pinkelpause.

Irgendwann beendet sich das Programm und man hat wieder Zugriff auf das Terminal.

Validierung

Validiert wird das ganze über das Programm dumpe2fs. Vorher hat es so ausgesehen:

root@home:/mnt~# dumpe2fs /dev/mapper/md0_crypt | head -n 100
dumpe2fs 1.42.10 (18-May-2014)
Filesystem volume name: <none>
Last mounted on: /mnt
[...]
Journal backup: inode blocks
Jounaleigenschaften: (none)
Journalgrösse: 128M
Journal-Länge: 32768
Journal-Sequenz: 0x00000004
Journal-Start: 0

Nach der Erweiterung sieht es so aus:

root@home:/mnt# dumpe2fs /dev/mapper/md0_crypt |head -n 100
dumpe2fs 1.42.10 (18-May-2014)
Filesystem volume name: <none>
Last mounted on: /mnt
[...]
Journal backup: inode blocks
Checksum type: crc32c
Checksum: 0xbfbb4b93
Jounaleigenschaften: journal_incompat_revoke journal_checksum_v3
Journalgröße: 128M
Journal-Länge: 32768
Journal-Sequenz: 0x00004130
Journal-Start: 1
Journal checksum type: crc32c
Journal checksum: 0xef7211e2

Hat also ohne Probleme geklappt.

Further Reading


Du hast einen Kommentar, einen Wunsch oder eine Verbeserung? Schreib mir doch eine E-Mail! Die Infos dazu stehen hier.

🖇️ = Link zu anderer Webseite
🔐 = Webseite nutzt HTTPS (verschlüsselter Transportweg)
Zurück