On Wed, Oct 12, 2016 at 3:29 PM, Chris Murphy <lists(a)colorremedies.com>
On Wed, Oct 12, 2016 at 6:29 AM, Gerald B. Cox <gbcox(a)bzb.us>
> On Tue, Oct 11, 2016 at 8:52 PM, Chris Murphy <lists(a)colorremedies.com>
>> About the rewrite comment: that did not come from a developer, and is
>> definitely overstated. In any case, rewrites are not inherently bad
>> news, there's a bunch of OpenZFS videos from last yearss summit in
>> which the developers talk about various things being completely
>> rewritten from scratch, some things more than twice. So kinda par for
>> the course, and given enough time things get rewritten anyway. XFS has
>> had substantial changes over its history including numerous on disk
>> format changes even before it found its way onto Linux.
> Could be, should be, may be... that's fine - but it all says the same
> thing... they
> don't know how much time it is going to take to fix - and who knows what
> priority is to get around to it. The advantages over what already is
> don't appear to be that compelling, especially when weighed with the
So you are saying that you started using raid56 when it was brand new,
before it had *any* kind of persistent repairing or device replacement
and only now, due to a bug that manifests remarkably less bad than the
normal behavior of everything else (minus ZFS), are you now
complaining? So basically this is, "I want it now!" complaint. Because
all the available information has been saying don't use raid56 for
production, but you did so anyway. This is a subjective change in your
evaluation. It has nothing to do with the state of Btrfs so you really
shouldn't blame it when your requirements have clearly changed.
Well no, what I said was that I thought that they might have a somewhat
after three years... instead I get that a rewrite may be required with no
idea of when it would ever
be production ready. If you think that is acceptable, more power to you.
I do not and I would
venture to guess that many reasonable people would think three years would
be ample time.
My requirements haven't changed... I just think the time to fish or cut
bait has come. I've cut
> When all this started I did some searches and found Kent Overstreet's
> bcachefs: https://goo.gl/U0UFfN
> He had some words about the different filesystems - and had this to say
> about btrfs:
> btrfs, which was supposed to be Linux's next generation COW filesystem -
> Linux's answer to zfs. Unfortunately, too much code was written too
> without focusing on getting the core design correct first, and now it has
> too many design mistakes baked into the on disk format and an enormous,
> messy codebase - bigger that xfs. It's taken far too long to stabilize as
> well - poisoning the well for future filesystems because too many people
> were burned on btrfs, repeatedly (e.g. Fedora's tried to switch to btrfs
> multiple times and had to switch at the last minute, and server vendors
> years ago hoped to one day roll out btrfs are now quietly migrating to
I have heard from a couple developers that it was a victim of its own
hype/success and too many feature additions without equivalent effort
on error reporting, debugging, and fault injection tools. I have yet
to hear a Btrfs developer say the core design or on disk format has
anything to do with the problems, but to the contrary. The comment
it's bigger than XFS is kinda funny, seeing as it does more than XFS,
md, and LVM combined, so a proper comparison would be comparing all of
them to Btrfs minus their user space tools (for sure Btrfs tools do
not come anywhere near the metric ass tonne of switches or
documentation in LVM or mdadm).
I can't speak for him, but don't believe that was his point. I read it as
code was bloated.
The Fedora report is simply nonsense. Fedora made no meaningful
attempt to switch to Btrfs once, let alone multiple times. FESCo
considered and approved it, with conditions attached.
Well, we're getting into semantics here. I would call that a serious
attempt - and there
are many articles that are available that talk about Fedora discussing
a default. If you don't consider any of those attempts "meaningful" I
a good thing.
pushing it off because he thought it wasn't ready.
Smart man, he was right.
And then Josef
moved on from Red Hat, and wasn't replaced. Characterizing this as
"tried to switch" and "had to switch at the last minute" is at best
Ok, if you say so. Again, that wasn't the way the media reported it.
It was a change proposal, and it never met the requirements
of either the proposer or FESCo for it to proceed further. No changes
in default happened in the installer that had to be reverted.
So change proposals aren't meaningful attempts.... OK... good to know.
Perhaps the secret of fast and stable fs development is a single
developer authored file system.
Not sure about that... but considering what has happened with BTRFS, that
indeed could be the case. The facts certainly appear to support it.