BTRFS: The Good, The Bad and The Ugly

[Ric Wheeler]

On 07/14/2011 08:28 AM, JB wrote:
> Josef Bacik<josef<at>  toxicpanda.com>  writes:
>
>> ...
>> We aren't aiming for "hopefully stable", we're aiming for actually stable
>> and reasonably safe.  If we don't meet certain basic requirements no
>> switch will be made and everything will carry on as normal.
>>
>> I'm not trying to shove Btrfs down peoples throats.  The last thing I
>> want is to switch over to Btrfs before it's fully ready for everybody
>> to be using it, which is why there are a bunch of requirements that
>> need to be met before the switch is actually met.
>> ...
> Well, as a Fedora's point man and contributor to BTRFS, you sound good.
> For that, we are glad to have you there.
> But we want to test your dedication a bit ...
>
> As you probably know, about a year ago, when BTRFS was still in early
> experimental stage, during some elementary evaluation and testing that
> yielded some really disastrous results, an issue was raised that the devs
> corrupted the b-tree algorithm that underlies the fs in question.
> The original b-tree algorithm was a result of an academic study, formulation,
> and empirical testing, and was subjected to scientific scrutiny.
>
> Obviously, when devs do some "adjustments" to such a finely tuned algorithm,
> it is imperative that they should immediately submit them for review, as is
> customary. The entire alogoritm has to be verified once again.
>
> So, basically, the entire BTRFS fs design was called into question.
>
> Even as of today, the status of BTRFS in Linux kernel, as described by its
> devs, is:
> [linux/kernel/git/torvalds/linux-2.6.git] / fs / btrfs / Kconfig config
> and
> [linux/kernel/git/next/linux-next.git] / fs / btrfs / Kconfig
>
> BTRFS_FS
>         tristate "Btrfs filesystem (EXPERIMENTAL) Unstable disk format"
>         ...
>           Btrfs is highly experimental, and THE DISK FORMAT IS NOT YET
>           FINALIZED.  You should say N here unless you are interested in
>           testing Btrfs with non-critical data.
>         ...
>            If unsure, say N.
>
> There is a suspicion by some people who follow BTRFS development that it is
> a botched attempt, right from the very beginning, at its fundament, and if
> so any layers put on top of it "to make it work" are equivalent to asbestos
> that provides fire protection but distorts quality of the building, but will
> become a liability in due time :-)
> In other words, it is a product of hillbillies, wielding a compiler and
> a language a la ax men.
> Btw, we have seen similar software dev's "activism" in Fedora that does
> exactly that, and does not not stand up to scrutiny :-)
>
> So, what is the true state of BTRFS ?
>
> Do *you* think this is enough to be Fedora's *default* fs ?
>
> JB
>
>

Hi JB,

Not much can be said to this kind of post, even with smiley faces it is hard not 
to take it the wrong way. Given that my family is from the hills of eastern 
Kentucky, I also find the "hill billie" comment off putting.

Josef and other btrfs contributors have a long history of providing enterprise 
class file systems for RHEL, upstream and Fedora. It is safe to say that you 
cannot book a ticket for travel, make a trade on the stock market or deal with 
google without "testing" code that the team has moved into production support 
given the wide spread of linux file systems.

We will not push for btrfs as a default unless it is safe.

You can help by testing stability and performance, contributing patches and 
taking part in the upstream discussions and feeding back results to this list 
and others.

Or you can sit back, relax and trust that developers who do file and storage for 
a living have zero interest in pushing something that is not ready.

Ric