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. > 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.
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
