Reiserfs Experiencing Turbulent Updates

Apr 30, 2009

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.

Related content

  • Faster Boot Planned for ReiserFS Partitions

    Under certain circumstances ReiserFS will check the whole filesystem on rebooting, although this is not actually necessary due to its journaling function. Kernel developers are currently discussing a patch that will accelerate the system launch.

  • ReiserFS Without Big Kernel Lock

    Even though reiserfs belongs to the veterans of journaling filesystems and established ext3 and ext4 as standard Linux filesystems, a new patch serves to markedly improve it.

  • File systems

    Many users just opt for the defaults and don’t think about the file system when they install Linux. But if better performance is your goal, it pays to do some shopping.

  • LINUX WORLD NEWS
  • Kernel News

     

comments powered by Disqus

Issue 169/2014

Buy this issue as a PDF

Digital Issue: Price $9.99
(incl. VAT)

News

njobs Europe
What:
Where:
Country:
Njobs Netherlands Njobs Deutschland Njobs United Kingdom Njobs Italia Njobs France Njobs Espana Njobs Poland
Njobs Austria Njobs Denmark Njobs Belgium Njobs Czech Republic Njobs Mexico Njobs India Njobs Colombia