Btrfs by default

The Workstation WG is tracking an issue for a first article to present “Btrfs by default” feature.

The Btrfs by default feature proposal has a list of benefits that probably should be mentioned, all or in part, in this article. An open question is what features to promote.

It’s important to properly communicate competing themes: providing Btrfs features transparently, and addressing common concerns. i.e. the good and the bad. It’s necessary to find the proper balance. Not addressing concerns possibly makes it look like a fluff piece. Addressing them too much will worry the reader.

What’s the first article’s purpose, audience, scope and prose? Possible components or themes:

  • The then, the now, and the future: i.e. btrfs problem upbringing, lots of bugs; but what do we know now that inspires confidence; and what do we imagine about the future usage of its features?

  • Hero’s narrative: ordinary life->seeking adventure->facing conflict->overcoming nemesis. In this sense the article is a call to participation by the Fedora community. Anyone can be a hero in the validation process, whether they are in favor, or skeptical, of the proposal. There is also a dual story because Btrfs is also an unproven hero+nemesis who will face challenge: the validation process.



I’m really looking forward to these articles myself. I guess my only suggestion would be to break down the articles into fairly small, but poignant, pieces to try to avoid overwhelming the readers to the point of “TLDR”. Maybe outline all the subjects to be covered beforehand and try to arrange them in a way that flows well from the basics to the more advanced topics.

Thanks! :slightly_smiling_face:


Also needing incorporation, is an article for another Btrfs test day. The tentative plan is something in the style of Fedora Magazine’s kernel test day articles.

+1 – it’s a good idea and I think more than one article is a great plan.

Created an article spec card on Taiga with a brief description. Taiga card #216.

1 Like

Hello @cmurf,
Have the WS WG members come up with a first article for the BTRFS by default series? I would think now is the time to introduce this idea for digestion prior to F33 stable release. I think the first article should be about the reason ext4 is considered outdated, perhaps. But possibly more important is a general filesystem discussion, and maybe a few specific reasons why BTRFS by default makes sense on a Fedora WS. The following article(s) should flesh out the presented ideas with details supporting the concept. An article about the differences between competing (with BTRFS) filesystems, such as XFS and ZFS to name just two alternatives of a modern filesystem with COW capabilities. Another article which delves into tuning the filesystem, such as using compression on various directories, and why you may want to. Another on doing backups using BTRFS send/receive. Another for recovery and maintenance maybe. Ideally, these should come once per week. Just looking at the magazine que, we have several articles already in progress and those will go to review mostly this week. There are several more in the spec column. This is all ahead of the potential articles you are wanting to publish. The editorial board members can bump articles to accommodate, but we need an article to publish. I don’t mind helping to get these written if you are having difficulty finding an author.

Personally, I would not use the claim that “ext4 is outdated”. It is still stable and fulfills its purpose. Many people would scream bloody murder. However, btrfs is much more feature-rich, and its extended capabilities beyond what ext4 provides should be the main focus.

That’s just my 2-cents worth. I have happily used btrfs for 6 years or longer.

1 Like

Sorry, wasn’t trying to upset anyone with the comment, it is derived from the ext4 wiki, in particular this quote from the creator/maintainer …

In 2008, the principal developer of the ext3 and ext4 file systems, Theodore Ts’o, stated that although ext4 has improved features, it is not a major advance, it uses old technology, and is a stop-gap. Ts’o believes that Btrfs is the better direction because “it offers improvements in scalability, reliability, and ease of management”.

I think that statement is important to acknowledge from a user POV. Just my 2c on that, nothing more. I feel the WS WG should be driving the roll out of this in any case.

1 Like

That’s ok. You didn’t upset me, I was just afraid it would upset many others.

It likely will, our species loathes change. I just like to look at the details around these types of decisions from the developers POV as well as the users. In a practical sense, I cannot imagine ever needing to address EiB of data, but I also used to build 48K mac clones thinking they were the coolest things on the planet and they were at the time, so go figure.

1 Like

I’m working on it this week. The first article I expect to cover bullet points 2, 3, 4 here:

The first article should emphasize practical benefits Btrfs brings, rather than direct comparison to what we use now. This helps set expectations, and it’s more positive language rather than critical. Also, a summary of the logical thought process involved with the decision, the fact this is not a done deal, that there are expectations, and there’s a validation process to follow.

A significant problem with the first article is avoiding scope creep. I think it necessarily needs to acknowledge it’s a big change, has big benefits, big expectations, and must run the gauntlet of validation - or flat out it isn’t happening for Fedora 33.

Therefore I think I’ll leave the Btrfs history out of the first article. It’s a bit more technical anyway.

However, I’m tempted to separate the partitioning aspect from file system, to convey a major benefit of Btrfs while also not blaming ext4 for the problem. As you can see from this pros/cons list the Workstation WG produced, we were pretty much committed to solving the partition problem no matter the file system, by dropping LVM. But at the same time I don’t want to get deep into the weeds of technical things in the very first article.


I am glad the articles are coming along since this is important to inform the community of. I agree about history as not adding value to the conversation opening. Some technical is good, TMI can be a problem in lengthy mag articles, you have already committed to writing several to cover the ground you want. Break it down as granular as you need to convey the message to your satisfaction. Details about the process for deciding if this proposal goes ahead or not would be well received I would think.

Incoming! I’ve got a draft for the first article that will land today. Word count is 1026. I’d like to get that to 750, which shouldn’t be difficult. Things can always be split out into additional articles.

What I’ve done with this first article is taken on bullet points 2 and 4 here. And I’ve been outlining part 2 mostly based on points 1 and 3. I’m not attached to which one is in fact part 1 vs part 2. But as QA folks want to have a test day soon, it seems the “why” and the “what” are more topical, and could be useful for recruiting testers . Recruitment is perhaps a weak point in the current draft, it may not go far enough.

Two problems I’m having.

  1. I don’t seem to have write access to the Taiga card, #216, so I can’t assign myself to it and set status.
  2. When I login to the wordpress instance using FAS, I get:
Powered by WordPress
OpenID login failed: No OpenID information found at
OpenID login failed: No OpenID information found at

You are being redirected, please wait.

Register | Lost your password?

I’m not sure if that’s due to some recent issues with FAS or if I just don’t have access to the wordpress instance yet.

FAS: chrismurphy
FAS email:
preferred email:

I got you set up as a writer on Taiga, and assigned you to the article which is currently in spec. You should be able to work on the Taiga card now.
Unfortunately I cannot do much for you on Wordpress as I have only limited roles there.

OK looks like the FAS issue has been resolved, and I have Wordpress access.

Should I file an issue for this article?

Or should I just drop what I have into Quick Draft?

The pagure issue instance may become obsolete if this method of proposal works better for the mag. The only caveat would be we (the editorial board) hasn’t decided on whether we have had success with it or not. I would put the details you have into a draft in any case since the article content should always be on WP.

Preview is here:

I set to “holding pen” but realistically it’s ready to for review and editing. Is this URL what should be used to share this with others who should be in on the review? e.g. Workstation working group? Or should they get the “preview” URL? I’m not sure the best way for multiple parties to collaborate on the review.

Normally you paste the preview link on the Taiga card. The editors watch both conversations here and at the Taiga instance. The bonus we have here is the community can and will jump into the conversation at times, as you likely saw. This weeks wednesday meeting it will come up for sure.

Your @cmurf user account was in our Taiga team, but not @chrismurphy. I’ve added the latter as well just in case.

1 Like

It might be helpful to link to Nest session: Getting Buttery with Fedora; once available.