On Wed, Oct 12, 2016 at 8:35 PM, Gerald B. Cox <gb...@bzb.us> wrote:
> On Wed, Oct 12, 2016 at 3:29 PM, Chris Murphy <li...@colorremedies.com>
> wrote:
>> On Wed, Oct 12, 2016 at 6:29 AM, Gerald B. Cox <gb...@bzb.us> wrote:
>> > On Tue, Oct 11, 2016 at 8:52 PM, Chris Murphy <li...@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,

devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Reply via email to