On Wed, Oct 12, 2016 at 8:35 PM, Gerald B. Cox <gbcox@xxxxxx> wrote: > > On Wed, Oct 12, 2016 at 3:29 PM, Chris Murphy <lists@xxxxxxxxxxxxxxxxx> > wrote: >> >> On Wed, Oct 12, 2016 at 6:29 AM, Gerald B. Cox <gbcox@xxxxxx> wrote: >> > On Tue, Oct 11, 2016 at 8:52 PM, Chris Murphy <lists@xxxxxxxxxxxxxxxxx> >> > 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 _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
