Legacy UNIX Dateisysteme und die EPOCH-Alypse

In diesem Artikel werden wir die Auswirkungen des Y2K38 Problems auf UNIX Dateisysteme genauer beleuchten und Lösungen diskutieren, um bereits heute für die Zukunft vorzusorgen.

Das Jahr 2038 Problem betrifft UNIX-basierte Systeme, die die Zeit als Anzahl der Sekunden seit dem 1. Januar 1970, auch bekannt als Epoch, zählen und diese in einer 32 bit signed Integer Variable speichern. Durch die Limitierung des verwendeten Datentyps erreicht dieser am 19. Januar 2038 seinen maximalen Wert.

Die Bedeutung von Zeit für Dateisysteme

Egal welches Dateisystem verwendet wird, ein Vorgang ist bei allen gleich: Beim Lesen, Schreiben und Verarbeiten von Dateien werden diese Zeitpunkte in Form eines Timestamps in den Metadaten der Datei festgehalten.

Wird der Timestamp des Systems durch den Y2K38 overflow erstmal negativ, werden wir vom 19. Januar 2038 zum 13. Dezember 1901 zurückversetzt. Die akribisch geführten Informationen in den Metadaten der Datei machen einfach keinen Sinn mehr. Versuchen wir trotzdem, unsere Dateien zu bearbeiten, kann dies unvorhersehbare Folgen haben. Datenverluste durch Fehler bei Lese- und Schreibzyklen sind denkbar, allerdings kann dies auch Auswirkungen auf grundlegende Systemprozesse haben.

Nehmen wir Fsck oder “File System Consistency Check” als Beispiel. Fsck ist ein Prozess, der den fehlerfreien Betrieb von Dateisystemen sicherstellen soll. Anhand der in /etc/fstab definierten Angaben wird bei Systemstart überprüft, ob alle Partitionen erwartungsgemäß funktionieren. Sind die Timestamps, die in den Metadaten aufgenommen wurden, nicht konsistent mit der geführten Systemzeit, wird dies schnell als Fehler interpretiert. Um diesen Fehler zu simulieren, muss man nicht bis 2038 warten.
Eine leere CMOS Batterie tut es genauso. Ist die Hardware Clock erstmal aus dem Takt, wird man beim Systemstart mit “Superblock last mount time in the future” begrüßt.

Der 5.10 Kernel Patch und Inodes

Glücklicherweise hat man dieses Problem schon frühzeitig erkannt und den 32 bit Linux Kernel in Version 5.10 mit einem 64 bit kompatiblen Timestamp Format gepatcht. Ist das System auf einem aktuellen Stand (Kernel Version >= 5.10) muss man sich keine Sorgen mehr machen, oder etwa doch?

Natürlich ist das nicht ganz so einfach. Nur weil das System in der Lage ist, einen UNIX-Timestamp nach dem 19. Januar 2038 zu verarbeiten, heißt das nicht, dass unsere Legacy Software auch etwas damit anfangen kann. Das gleiche betrifft auch unsere Dateisysteme. Eine schnell übersehene Fehlerquelle sind die sogenannten Inodes.

Stark vereinfacht sind Inodes Datenstrukturen, die Metadaten von Dateien und Verzeichnissen enthalten. Jedes Verzeichnis wird durch einen Inode beschrieben und verweist auf eine Liste der enthaltenen Dateien. Jede Datei wird durch eine oder mehrere Inodes repräsentiert, die auf die Festplattenblöcke verweisen, an denen sich die Daten der Datei befinden. Erstellen oder kopieren wir Dateien, werden weitere Inodes allokiert. Verschieben wir Dateien jedoch, findet ausschließlich ein Relabeling der bereits verwendeten Inodes statt.

Dateisysteme mit fixen Inodes

In vielen populären Dateisystemen wie ext2/3/4 (extendable FS) befinden sich Inodes in einem fixen Speicherbereich, welcher beim Erstellen des Dateisystems angelegt wird. Dieser Umstand bringt ein paar interessante Folgen mit sich.

Die Metadaten der Inodes benötigen Speicherplatz. Da der Platz, den wir für Inodes beim Erstellen des Dateisystems anlegen, limitiert ist, haben wir somit ein oberes Limit für die Anzahl an Dateien geschaffen, die wir auf unserer Festplatte speichern können. Anders ausgedrückt: Wenn unsere Festplatte 1000 freie Inodes hat, und wir 1000 leere Dateien anlegen, ist unsere Festplatte voll, egal wie viel freier Speicherplatz noch vorhanden ist.

Viel wichtiger jedoch ist, dass die Kompatibilität unseres Kernels keinen Einfluss darauf hat, ob wir einen 64 bit Timestamp in die fixe Speichergröße unserer Inode unterbringen können. Um dieses Problem zu lösen, müssen wir neue Inodes mit mehr Speicherplatz anlegen. Hier liegt das eigentliche Problem: Da die Aufteilung der Festplatte statisch ist, können wir die Größe der Inodes nicht einfach so anpassen. Die sauberste Lösung ist es, ein neues Dateisystem zu erstellen und alte Daten zu migrieren. Dies ist vor allem bei großen NAS-Arrays zeitraubend und arbeitsintensiv, schützt allerdings vor Datenverlust.

Da ext2 mittlerweile in den Ruhestand geschickt wurde [1] und auch ext3 keine 64 bit Timestamp Unterstützung bekommen wird, sollte eine Migration zu ext4 durchgeführt werden. Während ext4 kompatibel mit ext2/3 ist, also legacy Dateisysteme als ext4 gemountet werden können, ist es nicht immer möglich, ein ext4 Dateisystem in einem 32 bit UNIX System zu verwenden.

Um die neuen 64 bit Timestamps speichern zu können, sollte sichergestellt werden, dass die Inode Größe mindestens 256 Bytes beträgt. Es gibt durchaus Gründe, die Inode Größe noch höher anzusetzen. Je mehr Speicherplatz für Metadaten vorhanden ist, desto mehr Informationen aus dem Extended Attribute Set [2] können gespeichert werden. Vor allem Systeme, die SELinux Policies verwenden, benötigen diesen Platz. Größere Inodes bedeuten aber auch weniger Speicherplatz für unsere Dateien. Es ist also wichtig, ein gutes Maß zu finden, welches die benötigte Balance aus Speicherkapazität und Features abdeckt. Ein gut ausgebildeter Sysadmin oder DevOps kann hier eine Menge Zeit und Nerven sparen.

Dateisysteme mit dynamischen Inodes

Zusätzlich zu Dateisystemen mit fixen Inodes gibt es auch sogenannte dynamische Dateisysteme. Btrfs (aka “better FS”, aka “butter FS”, aka b-tree FS) ist ein sehr beliebtes Beispiel. Da Btrfs erst seit 2007 auf dem Markt ist und seit 2013 als stabil gilt, ist es zwar unwahrscheinlich, aber nicht unmöglich, dass diese Dateisysteme vom 2038 Problem betroffen sind.

XFS hingegen ist bereits seit den frühen 1990ern in Nutzung und wird auch heute aktiv verwendet. Auch hier wird nach einem Kernel Update nicht automatisch auf das neue Timestamp Format umgestellt. Ein Update der Dateisystem-Inodes ist jedoch sehr viel einfacher und durch die Verwendung des Bigtime Feature in xfs_admin möglich:

“Bigtime
Upgrade a filesystem to support larger timestamps up
to the year 2486. The filesystem cannot be downgraded
after this feature is enabled. Once enabled, the
filesystem will not be mountable by older kernels.
This feature was added to Linux 5.10.” [3]

Ein Wort zum Schluss

UNIX Dateisysteme werden aufgrund ihrer Stabilität, Geschwindigkeit und (bis auf wenige Ausnahmen) fehlenden Lizenzkosten in mehr Geräten verwendet, als man glauben mag. Wenn ihr nun also alle los zieht, um eure Server vor der EPOCH-Alypse zu schützen, vergesst nicht eure NAS Systeme, Smart Geräte und Netzwerk Equipment zu überprüfen. Wobei, wenn ihr so altes Netzwerk Equipment verwendet, habt ihr vermutlich größere Probleme als das Jahr 2038.

Quellen und weitere Informationen

Ext2 Dateisystem wegen 2038 Problem auf „deprecated“ gesetzt

[1] EXT2 Deprecation: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b960e8093e7a57de98724931d17b2fa86ff1105f

[2] Extended Attribute Set:
https://en.wikipedia.org/wiki/Extended_file_attributes#Linux

[3] XFS Admin Tool Manpage:
https://man7.org/linux/man-pages/man8/xfs_admin.8.html

Updates

• FreeBSD-Update auf 13.5 überarbeitet das „UFS1-Dateisystem“ (UNIX File System) – nun kann es Dateien und Ordner bis Februar 2106 um 06:28:15 UTC speichern (Link zur Meldung)

Autor