Ein Beitrag im Kernel-Bereich bei Linux Weekly News hat mal wieder einen interessanten Aspekt bei der Entwicklung moderner Dateisysteme beleuchtet, welcher nicht im direkten Fokus des Normalusers oder Administrators liegt.
Grundlegend geht es darum, dass der Speicherplatz wesentlich schneller wächst als alles andere. Eine „witzige“ Anekdote die durch diesen Fakt bedingt ist, ist die maximale zu verwaltende Speichergröße bei Ext4. Im aktuellen Ext4-Tree wird eine Blocknummer von 48 Bit genutzt, obwohl 64Bit locker möglich währen. Der Grund ist simpel. Selbst mit 48 Bit kann man 1 PByte verwalten und schon der Check dieser Datenmenge braucht unter aktuellen Bedingungen sehr lange (über 100 Jahre).
Es überrascht mich ein wenig wie deutlich der Autor des LWN-Artikels auf die Fehleranfälligkeit von SSDs hinweißt. Besonders da ich überlege damit meinen Server zu „upgraden“ …
Es ist jedoch interessant zu lesen, wie die Entwickler diesen Problemen versuchen zu begegnen. Ein Dateisystem das auf Wiederherstellung und Reparatur (s)eines defekten Zustandes optimiert ist. Es klingt für mich als Programmierer/(hobby)Administator ein wenig seltsam, dass ein Dateisystem davon ausgeht korrupt zu sein. Jedoch müssen wir uns wohl an diesen Umstand gewöhnen und geeignet darauf reagieren.
ChunkFS geht den Ansatzt, dass Fehler entweder global (totaler Verlust der Festplatte) oder lokal (einzelne Lesefehler) auftreten. Selten gibt es was dazwischen… Fast alle modernen Dateisysteme können mit ersterem nicht umgehen (außer über ein Fallback mittels RAID) und behandeln einen Lokalen defekt, indem sie die ganze Festplatte als „korrupt“ ansehen. Klingt irgendwie nicht sehr sinnig 😉
Chunk FS hingegen teilt „Festplatte“ in viele unabhängige Bereiche, die einzeln und online (im Background) wiederhergestellt werden können. Was freilich nur Sinn macht, wenn die Daten irgendwo redundant abgelegt sind. Noch gibt es keine wirklich praxistaugliches Implementation aber es ist wohl nur noch eine Frage der Zeit.