5

A DevOps colleague is recommending that we begin transitioning our production environment to using btrfs. We have primarily ext4 filesystems, though some low-usage servers using ZFS (on Linux). As one of the decision-makers, and as one responsible for our overall environment, I am hesitant based upon the number of comments and articles around btrfs in production on the web. To counter that argument Oracle has released their Enterprise Linux with btrfs support, SLES 12 (https://www.suse.com/releasenotes/x86_64/SUSE-SLES/12/) also indicates it will be using btrfs, and there is evidence that companies like Facebook are also using it in controlled production environments.

There are a number of arguments made as to why moving in this direction (adopting btrfs) will be a good thing, and I agree with them overall, however, I would like to be prudent, do due diligence, and get more operational familiarity and hours logged in a "small production" or staging environment before moving forward on a wider scale. Are there any tools that can help me build the case - as in stress testing followed by data integrity checks or something along those lines? Other than not seeing statements like: "Q. Is btrfs stable? Short answer: No, it's still considered experimental." on the btrfs wiki what else can I do to get a warmer fuzzy?

ewwhite
  • 194,921
  • 91
  • 434
  • 799
Joe
  • 472
  • 4
  • 15

2 Answers2

3

I've given an elaborate answer already here: Is btrfs production ready?

In short: Btrfs is nothing you already want on a production file server.

Here are the reasons why: it becomes unpredictable if space is running out, though most core features are considered stable, others aren't yet and it is still a fast moving target. Being a fast moving target means you should always use the latest and greatest kernel, which is something you don't want on a server.

Also even still with kernel 3.16 it is known to produce deadlocks, which is for sure something you don't want on a production server (http://marc.merlins.org/perso/btrfs/post_2014-10-05_Btrfs-Tips_-Catch-Btrfs-Deadlocks.html). Also some RAIDs are still experimental, like RAID5/6. You can use those, but not scrub data there yet and other stuff.

Fedora wants finally to make Btrfs maybe the default file system with v23, which is going to happen at the end of 2015. Red Hat switched from Ext4 to XFS as default now.

If you really need a COW production ready file system, do yourself a favor and take ZFS, either as ZFS on Linux or under FreeBSD.

And read Russel Coker's blog about his experience with Btrfs. http://etbe.coker.com.au/

Community
  • 1
Marc Stürmer
  • 1,894
  • 12
  • 15
2

I'd stick with mainstream filesystems like XFS (as promoted by Red Hat) and rely on ZFS for advanced filesystem needs.

This is mainly due to:

  • Mindshare: ZFS knowledge is held in the Linux, FreeBSD and Solaris/OpenIndiana communities.
  • Maturity: The ZFS codebase is proven and has been around for awhile. Best-practices have evolved and I can't recall seeing horror stories about data loss.
  • Portability: I've definitely changed platforms and retained ZFS compatibility throughout.

Short of specific integration with Linux containers, I don't know that BtrFS offers much over ZFS today. If you have hesitation about using BtrFS, listen to your gut. I don't think I'd bet the business on it, but things can change over time. Evaluate your specific needs. Are there compelling features in BtrFS that your environment can take advantage of?

Take a sample view of Server Fault questions about BtrFS to see what issues people routinely face.

Community
  • 1
ewwhite
  • 194,921
  • 91
  • 434
  • 799
  • I appreciate the sentiment of staying with XFS or ZFS. However, assume for arguments sake that I was just now looking at ZFS; the question remains, what sort of tools could I use to stress test it and validate data integrity (leave performance out of the equation for the time being)? – Joe Aug 29 '14 at 13:35
  • If you were just looking at ZFS, I'd say that most of that work has been done. It would be a matter of tuning to your specific workloads. [Here's an example workflow](http://serverfault.com/questions/617648/transparent-compression-filesystem-in-conjunction-with-ext4/617791#617791) to solve a specific application need. I don't know that stress-testing is needed, since ZFS tends not to crash in an ugly manner. For data integrity, try the normal drive failure scenarios, read up on the ZFS checksumming and run a periodic scrub of the data once the volumes are populated (`zpool scrub poolname`). – ewwhite Aug 29 '14 at 13:40
  • I did some checking into BTRFS stability and the answer is (as of April 2014) -- it is not quite ready yet. You really need to keep a very close eye on it as it is still possible for BTRFS to wedge itself. – tgharold Sep 12 '14 at 17:31
  • @tgharold When would you suggest people try to use BtrFS? – ewwhite Sep 12 '14 at 17:32
  • 2
    Well, SLES (Suse) 13.2 due out later this year is going to include BtrFS by default. But Red Hat still has it marked as a technology preview in RHEL 7.0. Personally, I would suggest not using it in production until early 2015 at the earliest if you are risk-adverse. Wait and see how SLES 13.2 goes, and whether Red Hat takes it out of "technology preview" status sometime in 2015. – tgharold Sep 16 '14 at 13:58