Btrfs: broken by design?

Partially...the part in question is the btree indexing. This is important because it is a core part of the filesystem but it is also the least exotic part of the FS.

The part that is much more performance critical is how do we use that index to track block reference counts and maintain snapshot integrity. Much of my initial work here was expanded by Yan Zheng, and I think his improvements are a better topic for research papers.

Here is a paper where they tried to replace the btrfs back reference tracking and measured some differences:

http://www.usenix.org/events/fast10/tech/full_papers/mack...

Another key part of btrfs is how do we spread checksumming or compression across the CPUs and still maintain good IO ordering.

Or, how do we track free space and not explode (both Josef Bacik and Yan Zheng have spent considerable time on this part).

If I were going to invest time in writing the papers, I'd pick one of those three because they are newer problems where more active research is going on.