On Wed, Mar 16, 2016 at 12:40 PM, Mark Haney <mark.haney@xxxxxxxxxxxxxx> wrote: > I was surprised that btrfs is still not considered production ready after > all this time. I don't recall ext3/4 taking this long to be considered > production ready. Weren't ext3/4 building on prior work with a lot of known problem areas that needed improving? Certainly the scope of work between ext2 and ext3, and ext3 and ext4, is much narrower than a.) starting a file system from scratch b.) is the first implemented btree cow filesystem, c.) has a long feature list that's only found in multiple other projects combined (ext4, XFS, device mapper/LVM, and md/mdadm) and quite a few features not found in others (compression, deduplication, sending/receiving file system trees including efficient incrementals, online fs shrink....more I'm not thinking of). What is production ready is a bit of a gray area. On the one hand, openSUSE and SLES use it by default (they have a couple upstream kernel developers). On the other, upstream kernel docs are really conservative and say it's not suitable for anything but benchmarking and review. openzfs.org has some videos from last year's conference, one of them is about the birth of ZFS. Buried in it is the observation that it seemed like 90% of the work was done in a year once they got to first kernel mount, but then it was another 10 years before fully confidently deploying it in an enterprise environment. Btrfs got its start about 6 years after ZFS. And it has more features than ZFS already, with a large pile of additional project ideas on the Btrfs wiki. There is understanding on linux-btrfs@ that more emphasis on stabilization over features is desired by some developers. But then in the last couple weeks is an RFC for an initial experimental per subvolume encryption implementation. And that's very cool, so it's sometimes hard to argue against features when the expectations of production stability aren't there. Once that changes, it's harder to get feature integrated that might risk stability. Nevertheless these days it's rare to see total data loss on the list. I've only seen that recently with raid56 setups. But whether I've got data on a raid6 LV with XFS, or Btrfs raid6, this would not be my only copy if the data is important. One of my Btrfs raid volumes has a flaky drive. This is unwise to do on purpose for production. But for testing, it's kinda cool because every once in a while Btrfs detects corruption the drive did not, and fixes it. The good copy goes to user space, and it's also written back to the bad device to fix it. That's normal operation, nothing special. The same thing happens every so often on a manual scrub of all data. If there's no raid? Corrupt data doesn't go to user space. It's a failed read. Yes, you can use btrfs restore to extract the file offline anyway, if it happens to be your only copy, such as it is. So this is all pretty neat, is it the end of the world to not have such behavior in a file system? Not at all. We're very lucky to have the choices we have. > Of course, had I done due diligence, I wouldn't have put > a couple of btrfs based web servers in production before finding that nasty > item out. Fortunately, I replaced them with ext4 servers before they blew > up. > > On that note, is Fedora going to offer native ZFS any time soon? I know > Ubuntu 16.04 will release with it native. My guess is no way. Meanwhile, Canonical dithers over the legality of doing so, and their lack of contributing to Btrfs stabilization is telling. They'll get publicity out of the controversy, so it's free marketing. And they will get something probably more production ready than anything else for running containers. But I won't be surprised if they move to something actually in Linux land down the road. -- Chris Murphy -- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
