Als Jeff Mahoney eine Reihe von Patches zu Reiserfs einsandte, ging er davon aus, Reiserfs würde sich von nun an in einem eingefrorenen Maintenance-Zustand befinden. Doch es kam anders.

Gleich 35 Patches schickte der Suse-Entwickler Ende März an die Kernel- und die Reiserfs-Mailingliste. Die meisten davon hatten ihren Weg zwar in die Releases von OpenSuse gefunden, aber noch nicht in den Kernel. Mit der Patch-Serie wollte Jeff Mahoney den Kernel 2.6.30 auf den aktuellen Reiserfs-Stand von OpenSuse bringen und er schloss seine Mail mit den Worten:

“Once this is applied, I expect reiserfs to be in deep maintenance-only mode.”

Kurze Zeit später meldete sich Linus zu Wort, dass er die Patches bereits in den Kernel aufgenommen habe und riet Mahoney, die Änderungen ausgiebig zu testen, da er (Linus) selbst keine Reiserfs-Partitionen mehr betreibe. Um einen Scherz nie verlegen, beendete Linus seine Mail mit einem kurzen Kommentar, dass er nicht mehr mit einem solchen Patch gerechnet hatte:

“Heh, I hadn’t expected even this.”

Obwohl Novell das Dateisystem für seine Enterprise-Produkte noch ein paar Jahre pflegen muss, schien damit die Geschichte von Reiserfs 3.6 beendet zu sein.

Doch bereits am nächsten Tag meldete sich der Kernelentwickler Ingo Molnar zu Wort und wies darauf hin, dass Frédéric Weisbecker im Rahmen des kill-the-BKL-Projekts daran arbeitet die Big Kernel Locks von Reiserfs zu entfernen. Reiserfs gehört zu den Dateisystemen, die relativ intensiv von BKLs Gebrauch machen. Seit Kernel 2.6.26 arbeiten zahlreiche Entwickler daran, diese Big Locks aus dem Kernel zu entfernen und den Code granularer zu gestalten. Ingo Molnar legte zu diesem Zweck einen separaten Tip-Baum an, den “kill the Big Kernel Lock (BKL)“-Baum.

Innerhalb dieses Baumes arbeitet Frédéric Weisbecker nun daran, den Code von Reiserfs so umzuschreiben, dass das Dateisystem keine BKLs mehr nutzt. Damit bereitet er den Reiserfs-Nutzern gleich zwei Freuden: erstens nutzt das Dateisystem in Zukunft tatsächlich keine BKLs mehr und zweitens finden die Locks, welche das Dateisystem weiterhin braucht, per Superblock (in der Regel per Einhängepunkt) statt und nicht wie bisher über alle Dateisysteme hinaus, was zu einem Performance-Schub auf Systemen mit mehrern Reiserfs-Partitionen und Mehrkernprozessor führt, dem typischen Setup von Reiserfs in einer Serverumgebung also.

Da die Patches von Weisbecker Reiserfs in einer fundamentalen Weise verändern, bleiben diese vorerst im speziellen Git-Baum und fließen erst nach intensiven Tests in den Kernel ein, in jedem Fall erst nach Kernel 2.6.30.