| |||||||||||||
Btrfs: broken by design?Btrfs: broken by design?Posted Jun 26, 2010 13:52 UTC (Sat) by johnflux (subscriber, #58833)In reply to: Btrfs: broken by design? by masoncl Parent article: Btrfs: broken by design?
> When designing btrfs we took a big pile of known solutions for filesystem problems, crammed them together, and then fixed up the new problems that resulted. Somehow I missed the scientific magazine step that all the other filesystems have followed, but I'll do what I can to keep improving the FS.
Out of interest, what are your reasons for not having a peer reviewed article on this? Lack of familiarity of the process and/or time, would be my guess?
Especially since you benefited from reading a published paper, it would be nice for you to write up your changes. If you just don't want to go through that bother, maybe a "comment" would be nice? These are half-a-page comments to existing papers but they also get peer reviewed and published.
Actually, you mentioned that you worked with author of the original paper. Maybe he would be interested in publishing your work on your behalf.
(Log in to post comments)
Btrfs: broken by design? Posted Jun 29, 2010 20:40 UTC (Tue) by masoncl (subscriber, #47138) [Link]
>Out of interest, what are your reasons for not having a peer reviewed article on this? Lack of familiarity of the process and/or time, would be my guess?
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.
|
|||||||||||||