Reiserfs Experiencing Turbulent Updates
When Jeff Mahoney sent in a bunch of patches for reiserfs, he assumed that the filesystem would be frozen in maintenance mode from that point on. Things turned out differently.
The end of March, SUSE developer Jeff Mahoney had sent 35 patches to the kernel and reiserfs mailing lists. Most of them found their way into openSUSE, but not yet into the kernel. With the patch series, Mahoney wanted to bring kernel 2.6.30 to the current reiserfs state of openSUSE. He ended his thread with, "Once this is applied, I expect reiserfs to be in deep maintenance-only mode."
Shortly thereafter, Linus Torvalds responded that he merged the patches into the kernel. He advised Mahoney to thoroughly double-check the results, because he didn't have any remaining reiserfs partitions. Never to miss a joke, he ended his thread with "Heh, I hadn't expected even this" in response to Mahoney's expectation that reiserfs would go into maintenance mode.
Even though Novell needed to support the filesystem for its Enterprise products a couple more years, that seemed to be the end of the story. But a few days later kernel developer Ingo Molnar chimed in on the thread reporting that Frédéric Weisbecker, in the context of the kill-the-BKL project, was still working on removing big kernel locks (BKLs) from reiserfs. Reiserfs was a filesystem that still relied heavily on BKLs and many developers had been working on removing them as of Kernel 2.6.26. Molnar had created a special "tip:kill the Big Kernel Lock (BKL)" tree for the purpose, and Weisbecker was busily rewriting the reiserfs code to eliminate BKLs from it.
Because Weisbecker's BKL patches would change reiserfs in a fundamental way, they initially sat in a special -git tree and were only to flow into the new kernel after some intensive testing, at least not until Kernel 2.6.30. But Weisbecker's patches would be a boon for many reiserfs users. Not only would the filesystem cease using BKLs, but the locks that reiserfs subsequently needed would be by superblock (by attachment point as a rule) and not across the entire filesystem. It would lead to a performance leap on systems with multiple reiserfs partitions and multicore processors, a typical scenario for reiserfs in a server environment.