While some of the items merged are very handy and useful, anything that can break a filesystem should be used with extreme care in lab conditions. I've applied the new restriper and the new parser code to my btrfs-progs on a NAS system I've built, but the fsck I will not touch. I figure if I have a filesystem that's become corrupt at this stage in the BTRFS development cycle, they'll probably want to see it before I try to fix it so they can find out what happened and maybe fix a bug.
But as far as the time it's taken BTRFS to get to this point, I'm actually thinking it's right on track. These days filesystems have so many features internally that need to be designed, written and tested that it's a serious undertaking. Add on top of that all of the externally-facing features modern operating systems expect a filesystem to have, and you've got a substantial project on your hands. Now, add in the fact that you're developing a way to store and retrieve data that could be critical and/or expensive and you've raised the bar well beyond where it's ever been before.
When the ext2 filesystem was first written, there weren't as many interfaces, drives were considerably slower, caching and scheduling systems were not nearly as complex or intelligent as they are now, and let's face it- Linux wasn't very popular. Now with things like SSDs becoming ever more common place, massive hardware support, bad behaviors being worked around, and the features an enterprise like Oracle will want...I wouldn't want to be starting a new filesystem project.
Anyway, hopefully after Oracle ships a distro with BTRFS as the primary filesystem we will see a large wave of adoption and code maturity (not to say the code isn't mature...but more users = more corner cases). I'd love to have an in-kernel filesystem capable of closing the feature gap on ZFS!
P.S. The community on the BTRFS mailing list is probably the most approachable and friendly community I've seen in a very long time!


Reply With Quote


