1. Computers
  2. Display Drivers
  3. Graphics Cards
  4. Memory
  5. Motherboards
  6. Processors
  7. Software
  8. Storage
  9. Operating Systems

Facebook RSS Twitter Twitter Google Plus

Phoronix Test Suite


Fedora 17 Is Still Trying For Btrfs By Default


Published on 07 February 2012 10:24 AM EST
Written by Michael Larabel in Fedora

The Fedora / Red Hat developers working on the Beefy Miracle are tentatively moving ahead with their plan to use Btrfs as the default Linux file-system for Fedora 17 and beyond.

Yesterday was another Fedora Engineering Steering Committee (FESCo) where the committee discussed the latest round of F17 features, after approving an impressive amount of features for this next Red Hat-sponsored Linux distribution release. With the feature freeze being today (7 February), yesterday was the last FESCo meeting where new Fedora 17 features were approved.

The unified /usr file-system still has the go-ahead, English Typing Booster, firewall-d as the default firewall solution, and Network Zones were all of the Fedora 17 features discussed and approved yesterday. But perhaps most interesting is that Btrfs as the default file-system was brought up again.

The summary/minutes for yesterday's FESCo meeting states "AGREED: We'll try btrfs by default as long as it lands in alpha - if not, push to F18." So Fedora developers have until the Fedora 17 Alpha release to switch from EXT4 to Btrfs by default otherwise it will happen with Fedora 18. Fedora 17 Alpha is set to be released at the end of the month (28 February).

Those not familiar with the Fedora 17 Btrfs file-system proposal, the information is available from the Fedora Project Wiki. The scope is to enable Btrfs as the default file-system on new Fedora Linux installations rather than EXT4. Btrfs has long been available as an install-time option in Fedora (and in Ubuntu, openSUSE, and other Linux distributions) but would be the first tier-one Linux distribution switching to the file-system by default.

Btrfs support in Fedora has been interesting going all the way back to the Fedora 13 release where it gained support for Linux system roll-backs by taking advantage of the Btrfs copy-on-write snapshots within Yum.

Btrfs was supposed to become the default file-system in Fedora 16 but in the end the switch was postponed since a proper fsck utility for Btrfs was not ready, among other blocking bugs.

A proper Btrfs fsck utility is imminent (by next week) as Oracle is making Btrfs production-ready within their next Oracle Enterprise Linux release and SUSE Linux Enterprise Server is also needing btrfs.fsck for their next enterprise release in order to correct any file-system errors.

On the Red Hat BugZilla is the Btrfs tracking bug for Fedora. There's still seven open bugs while three have been closed. Among the open Btrfs bugs remaining is poor performance using Btrfs for VM storage, the lack of a working fsck (what should be fixed soon), support for creating Btrfs images with livecd-tools package, support for "various special things" Btrfs does in the installer, verifying Btrfs support works properly, a buffer overflow in Btrfs if the device name is too long, and a particular Btrfs file-system corruption/crash situation.

If these Btrfs bugs are worked out by the alpha release in about two weeks -- along with the expected premiere of the new Btrfs fsck -- and Btrfs flipped on within the Anaconda installer, we will have this next-generation open-source file-system as the default in Fedora 17. If it doesn't happen for the "Beefy Miracle" release, it should definitely be a good candidate for Fedora 18 considering the remaining open issues have been whittling away.

Fedora 17 final is due for an official release in early May with lots of new features. Below is the relevant FESCo IRC discussion from yesterday regarding Btrfs.
18:17:37 [mjg59] #topic #704 F17 Feature: BTRFS default file system https://fedoraproject.org/wiki/Features/F17BtrfsDefaultFs
18:17:41 [mjg59] .fesco 704
18:17:42 [twoerner] t8m: NetworkManager stores the zones for connections
18:17:42 [zodbot] mjg59: #704 (F17 Feature: BTRFS default file system https://fedoraproject.org/wiki/Features/F17BtrfsDefaultFs) – FESCo - https://fedorahosted.org/fesco/ticket/704
18:17:52 [mjg59] josef: You here?
18:17:54 [josef] yup
18:17:57 [twoerner] thanks, guys
18:18:07 [mjg59] josef: So really definitely actually btrfsck?
18:18:16 [josef] yup he's doing all the cherry picking now
18:18:21 [josef] says it will be ready tomorrow morning
18:18:21 [mitr] Is anaconda able to handle this right now?
18:18:30 [josef] anaconda has all the kickstart stuff and it works for hte auto partitioning
18:18:47 [josef] but heres the gotcha, you wont get any fancy stuff if you do a custom partiotn setup
18:18:53 * nirik would prefer to land in f18.
18:19:11 [josef] i dont think thats a huge deal since i wasnt planning on anaconda being able to do anything fancy at first anyway
18:19:17 [limburgher] fancy such as. . . ?
18:19:25 [josef] subvols, raid, compression etc
18:19:36 [notting] how often are we discovering any new data-eaters?
18:19:40 [pjones] yeah, we're looking at very basic support right now
18:19:50 [josef] notting: no big dataeaters since the last one
18:19:53 [drago01] what about the "omg it kills vms" bug?
18:19:53 [mjg59] josef: And we're now stable and don't have any known critical crash-my-system-and-eat-my-data issues?
18:20:02 [notting] josef: the last one?
18:20:07 [limburgher] josef: :)
18:20:15 [limburgher] josef: That's always true. :)
18:20:19 [josef] so we had a problem with our barrier code so if you crashed the box at the right second you'd lose stuff
18:20:30 [josef] but we built this nice cool tool to verify stuff
18:20:31 [pjones] limburgher: always except once, anyway ;)
18:20:37 [josef] so we're pretty confident its all ok now
18:20:48 [limburgher] pjones: Fair. :)
18:20:54 [josef] if worse comes to worse i have this really cool restore tool that will pick up the peices and get all of your data back :)
18:21:13 [limburgher] josef: So you keep the baby pictures on it currently then? :)
18:21:15 [josef] but we spent a lot of time verifying that we were doing everything right with our barriers to make sure we dont have this problem
18:21:20 [josef] i do
18:21:34 [josef] all my boxes (exception for my devel box of course) are btrfs
18:21:44 [josef] same goes for chris
18:21:49 [josef] been that way for years
18:22:04 [mjg59] josef: Ok, so you're good with people coming to your house and setting you on fire if this all goes awfully wrong?
18:22:13 [sgallagh] Just as a notable data point: I've been running with a btrfs filesystem since F16 beta. I can vouch for its stability in an assortment of workloads.
18:22:14 [josef] yup
18:22:20 [mjg59] Ok, good enough for me
18:22:28 [pjones] sgallagh: not really a useful datapoint, no.
18:22:34 * nirik had a corrupted btrfs install, but josef worked hard to get my data back, and I did.
18:23:01 [josef] worse comes to worse its pretty easy to make anaconda go back to what we had (afaik)
18:23:13 [notting] sure, but the josef-get-your-data-back service doesn't scale
18:23:17 [nirik] I'd still prefer to land in f18 (land right after branch) and give time to have the cool features and test out things much better.
18:23:31 [mmaslano] nirik: me too
18:23:41 [mjg59] pjones: Switching the default back is achievable?
18:23:44 [limburgher] nirik: nods
18:24:06 [josef] yes waiting till f18 gives us a nicer looking release with more complete anaconda support
18:24:12 [pjones] mjg59: no reason it wouldn't be.
18:24:19 [mitr] mjg59: for new installs anyway
18:24:21 [mjg59] josef: How valuable would the testing in F17 be?
18:24:22 [sgallagh] josef: Sounds like you're arguing to defer
18:24:25 [nirik] josef: what about live media?
18:24:45 [pjones] sgallagh: no, not defer - split between minor and major feature sets.
18:24:55 [josef] mjg59: i think very valuable, we're getting to the point where it's mostly stable for us, we need users to break it in new and interesting ways ;)
18:25:04 [drago01] are we planning to do btrfs convert on upgrades?
18:25:06 [josef] nirik: i havent done anything for live media
18:25:07 [notting] that sounds like an excellent opt-in feature :)
18:25:08 [sgallagh] pjones: Ah, ship all the features but not flip the "default" switch?
18:25:10 [drago01] or new installs only?
18:25:20 [josef] new installs only
18:25:27 [drago01] ok
18:25:36 [josef] afaik live media will probably have to stay on ext whatever
18:25:39 [josef] for now
18:25:41 [pjones] sgallagh: btrfs tools support more complex options that anaconda simply won't be using at this time.
18:25:47 [sgallagh] ok
18:26:05 [notting] "need users to break it in new and interesting ways" screams like a bad idea for people's data. now, if we had some large scale *system* installations where we could swap 25% of them for btrfs and test the results, sure
18:26:11 [sgallagh] Sorry, my knowledge level on btrfs is limited to "it's the Next Big Thing we should all be testing".
18:26:35 [mjg59] Do we still have time to make the change pre-Alpha?
18:26:46 [sgallagh] mjg59: Oh, HOURS at least :)
18:26:53 [notting] freeze is tomorrow, so, sure!
18:26:57 [mjg59] Ok, so
18:26:59 [sgallagh] notting: Not quite
18:27:25 [pjones] that's a question for dlehman I guess.
18:27:26 [sgallagh] notting: According to dgilmore: "plan on landing today. tomorrow is too late"
18:27:41 [mjg59] Proposal: Switch to btrfs by default for alpha. Revert if it's overly bumpy.
18:27:46 [pjones] mjg59: +1
18:27:53 * notting points dgilmore at rbergeron to get everyone on the same page w.r.t. communications
18:28:20 [mmaslano] -1 fsck is here for only a while. I'd rather see it in F-18
18:28:22 [mitr] Was the VM question answered yet?
18:28:27 [josef] so what do i do if i dont get the package built before the branch, just pull the f17 branch and update it?
18:28:31 [sgallagh] Yeah, the source of this was me asking rbergeron for clarification and getting dgilmore's answer of "tonight"
18:29:03 [mjg59] I'm +1
18:29:15 [mjg59] Any other votes?
18:29:21 [limburgher] I'm on the fence.
18:29:21 [sgallagh] I'm also -1 for F17. I think we're a bit too close to the line here.
18:29:22 [notting] i'm -1
18:29:23 * nirik ponders
18:30:06 [mitr] josef: KVM performance?
18:30:07 [notting] it would be interesting if we could enforce separation where it would be the default for system partitions but not data partitions
18:30:17 [nirik] yeah, -1 I guess. I'd like to see us use it all around with nice features and also have some time to see that fsck is working well in the wild.
18:30:24 [t8m] I'm +0 I think btrfs might be ready for general consumption now however without the full support in anaconda, does it make really sense to switch?
18:30:26 [josef] mitr: been something i'm working on, we're getting better but not quite to ext* speed yet
18:30:29 [mjg59] +2/-4 at present, then
18:30:53 [pjones] t8m: honestly from the anaconda POV, we'd rather have a release with the basic support so we can isolate bugs from it vs our big UI redesign.
18:30:53 [mjg59] And with a +0 it's not going to reach +5
18:30:55 [mitr] I'm +1 to the idea, but I think this really needs to land (including the anaconda default flip) for Alpha - is that manageable?
18:31:10 [pjones] the anaconda default flip is not a big change.
18:31:29 [t8m] pjones, ok that's good idea
18:31:34 [sgallagh] mitr: I don't think we can allow this to land post-alpha. Alpha is supposed to be feature-complete and testable
18:31:46 [t8m] ok changing my vote to +1 if it lands pre-alpha
18:31:48 [sgallagh] If it lands post-alpha, it won't be installable until beta, which isn't enough time for testing
18:31:59 [mjg59] +3/-4
18:32:14 [mitr] sgallagh: right
18:32:20 [mjg59] Just waiting for nirik and limburgher I think?
18:32:25 [limburgher] I think so.
18:32:42 [mitr] mjg59: I count +4
18:32:43 [nirik] I was -1
18:32:52 [limburgher] Reluctant +1 if pre-alpha.
18:33:20 [mjg59] Oh, yeah
18:33:21 [mjg59] Ok
18:33:26 [mjg59] So that makes +5/-4
18:33:38 [drago01] so we basically would end up with two different default file systems depending on install method / media?
18:33:43 [drago01] doesn't sound right to me
18:33:44 [mjg59] Which I guess means we're going to give this a go?
18:33:50 [pjones] I _think_ the anaconda change is roughly http://fpaste.org/p9zw/
18:33:53 [nirik] drago01: yeah, it would.
18:33:59 [sgallagh] That vote is still a little skewed
18:34:11 [sgallagh] Some were unqualified +1, others only pre-Alpha
18:34:21 [mjg59] sgallagh: I think the assumption is pre-Alpha, yes
18:34:23 [sgallagh] Do we assume that makes the whole vote "yes, if pre-Alpha"?
18:34:24 [pjones] I think pre-alpha is the working assumption there
18:34:25 [josef] and pre-alpha means today right?
18:34:29 [sgallagh] (Just wanted to clarify)
18:34:29 [pjones] josef: right
18:34:31 [nirik] yeah, asap
18:34:32 [sgallagh] josef: Yes
18:34:34 [mjg59] Ok
18:34:42 [josef] ok so if i miss that i'm screwed?
18:34:50 [pjones] only for six months!
18:34:52 [josef] haha
18:34:52 [mjg59] #agreed We'll try btrfs by default as long as it lands in alpha - if not, push to F18

About The Author
Michael Larabel is the principal author of Phoronix.com and founded the web-site in 2004 with a focus on enriching the Linux hardware experience and being the largest web-site devoted to Linux hardware reviews, particularly for products relevant to Linux gamers and enthusiasts but also commonly reviewing servers/workstations and embedded Linux devices. Michael has written more than 10,000 articles covering the state of Linux hardware support, Linux performance, graphics hardware drivers, and other topics. Michael is also the lead developer of the Phoronix Test Suite, Phoromatic, and OpenBenchmarking.org automated testing software. He can be followed via and or contacted via .
Latest Linux Hardware Reviews
  1. Preview: AMD's FX-9590 Eight-Core At Up To 5.0GHz On Linux
  2. Intel Launches The Core i7 5960X, Mighty Powerful Haswell-E CPUs
  3. AMD Radeon R9 290: Gallium3D vs. Catalyst Drivers
  4. AMD Radeon R9 290 Open-Source Driver Works, But Has A Ways To Go
Latest Linux Articles
  1. How Intel Graphics On Linux Compare To Open-Source AMD/NVIDIA Drivers
  2. The Fastest NVIDIA GPUs For Open-Source Nouveau With Steam Linux Gaming
  3. Testing For The Latest Linux Kernel Power Regression
  4. The Most Energy Efficient Radeon GPU For AMD Linux Gaming
Latest Linux News
  1. Marek Lands Radeon Gallium3D HyperZ Improvements
  2. Mozilla Firefox 32 Surfaces With HTML5, Developer Changes
  3. Nouveau X.Org Driver Released With DRI3+Present, Maxwell, GLAMOR
  4. Microsoft & AMD Release C++ AMP Compiler With Linux Support
  5. AMD, Wine & Valve Dominated August For Linux Users
  6. Linux 3.17-rc3 Kernel Released Back On Schedule
  7. Lennart Poettering Talks Up His New Linux Vision That Involves Btrfs
  8. Mesa 10.3 RC2 Arrives Via Its New Release Manager
  9. Ubuntu 14.10's Lack Of X.Org Server 1.16 Gets Blamed On AMD
  10. MSI Motherboard BIOS Updating Remains A Pain For Linux Users
Latest Forum Discussions
  1. Lennart Poettering Talks Up His New Linux Vision That Involves Btrfs
  2. Best Radeon for a Power Mac G5?
  3. The dangers of Linux kernel development
  4. Updated and Optimized Ubuntu Free Graphics Drivers
  5. AMD Releases UVD Video Decode Support For R600 GPUs
  6. SSD seems slow
  7. Is laptop with Intel CPU and AMD dGPU worth buying considering especially AMD Enduro?
  8. Radeon HD5670 and Ubuntu 14.04