9:08 p.m.
On Wed, Oct 12, 2016 at 8:35 PM, Gerald B. Cox <gbcox(a)bzb.us> wrote:
On Wed, Oct 12, 2016 at 3:29 PM, Chris Murphy <lists(a)colorremedies.com>
wrote:
>
> On Wed, Oct 12, 2016 at 6:29 AM, Gerald B. Cox <gbcox(a)bzb.us> wrote:
> > On Tue, Oct 11, 2016 at 8:52 PM, Chris Murphy <lists(a)colorremedies.com>
> > wrote:
> >>
> >>
> >> 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
> > their
> > priority is to get around to it. The advantages over what already is
> > available
> > don't appear to be that compelling, especially when weighed with the
> > risks.
>
> 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
stable product
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
bait.
>
>
> >
> > When all this started I did some searches and found Kent Overstreet's
> > page
> > on
>
> > 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
> > quickly
> > 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
> > who
> > years ago hoped to one day roll out btrfs are now quietly migrating to
> > xfs
> > instead).
>
> 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
that the
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
making BTRFS
a default. If you don't consider any of those attempts "meaningful" I
suppose that's
a good thing.
>
> Josef kept
> 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
> hyperbole.
Ok, if you say so. Again, that wasn't the way the media reported it.
I'll say so. I was the only one ever pushing it, and only mildly at
best. Each time it was a discussion about what would the requirements
look like to switch over so I knew what targets needed to be hit. In
the end I felt like it wasn't worth the effort to try and switch
Fedora over, Suse has way more inhouse expertise and willingness to do
the work so I figured that was good enough and just gave up trying to
switch Fedora over.
>
> 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.
They weren't meaningful attempts, like I said above they were attempts
to get the conversation started and to see what work would be
required. Every time I felt my time was way better spent working on
btrfs than dealing with the Fedora community. Thanks,
Josef