On 03.09.2016 23:40, Richard Brown wrote:
On 3 September 2016 at 18:24, Chris Murphy
wrote: On Fri, Sep 2, 2016 at 8:27 PM, Jeff Mahoney
wrote: No, it's not. We publish the code for every single one of our kernels both in patch series and expanded tree form. Every maintenance update is tagged and even if they weren't, the last commit that was included in the RPM is included in the RPM metadata. We also have a very longstanding, public policy regarding code going upstream and a outsize percentage of our kernel teams in upstream maintainer roles. So you can imagine that when someone suggests that we're not being good community members with our kernels, it ruffles a few feathers. You're the one leveling an accusation (using typically incorrect assumptions). You bring the proof.
1. On the Btrfs mailing list, most every time anyone has a quota problem, they're informed if they need stable quota support to use XFS or ext4. And not a single Btrfs developer ever contradicts that advice in the slightest way. And this most recent non-contradicted advice happened just a few weeks ago.
Well now you've seen at least one of our btrfs developers contradicting that advice. And it's not like Jeff is some novice who doesn't know what he's been talking about, he's been intimately involved with the kernel and explicitly btrfs and other filesystems for years now. He knows what he's talking about, he's very rarely wrong, and he is one of those boring "don't change anything, ship it only when it's absolutely ready" Enterprise developers. And even IF he is wrong, it's going to be the job of him and his team to fix it in both SLE and openSUSE, so you can take extra reassurance from that.
And he works for SUSE, and SUSE has invested a lot of time, effort, engineering and testing on this. You've heard of the testing Jeff's team has done. In addition I can tell you that SUSE QA have been doing additional testing on btrfs qgroups and shaken out a corner case bug or two, but nothing that would classify as a 'Ship Stopper'. SUSE's Beta customers have all been using the feature also as part of the SLE 12 SP2 Open Beta programme.
You've heard of the strategic importance of this feature from Matthias, SUSE's Senior Director of SLE Product Management. As a default option in our installation, almost all of SUSE's customers will be relying on this to work when they install SLE 12 SP2 at the end. SUSE isn't going to do that unless it's confident in the quality of the feature and its ability to support it for years.
As an openSUSE contributor, you have an opportunity to contribute to this and to bring additional knowledge and data points to the table, but that comes with a responsibility to ensure that your data is accurate, correct, reproducible and actionable. By quoting random commits and mailinglist threads you do not have a full understanding of, while actively rejecting any suggestion to do your own testing, you have failed to contribute responsibly to this discussion.
The very first time I have ever read anywhere, by any Btrfs developer, that enabling quotas is considered stable, was on this list.
You heard it here first :)
Matthias, Richard, and some of your comments, while circumspect, can be inferred to mean your quota code substantially differs from the current stable kernel, and that's why you consider it stable. But then just yesterday you say "the only [Btrfs] patches we have applied to the 4.4-based SLE12-SP2/Leap kernel are backports and patches we've submitted upstream".
You were invited to help confirm the issues you feared were present in the 4.4 LTS Kernel used by Leap 42.2 or SLE 12 SP2. You were given advice from Jeff on how to do this. You have outright refused to do so, so frankly I feel you have no credibility to imply that there are deeper issues.
To put it very directly, with all due respect, either contribute or shut up - this is a mailinglist for contributors to discuss the development of the openSUSE distributions, not a soap box for ill-informed rants.
I can't and will not say anything about particular bug discussed here BUT I think many people will agree that the reason why so many are getting those insane "not enough space" btrfs error varieties over the _years_ is that it's main purpose is to provide zfs-like enterprise features to corporation with big data storages while small-time enterprises and SOHO users of openSUSE and alike are readily treated as mere guinea pigs for that use case, meaning that openSUSE itself is an eternal "corner case". Recently, the distribution installer was removed from TW "due to bugs" while the only bug of that installer that I've ever seen is another "not enough space" right in the middle of installing 12Gb worth of packages on fresh ~20Gb-sized btrfs partition which I successfully have done multiple times before with different live builds and machines. Yeah, remove the installer of the system, not the thing that breaks it, that makes sense... Also a nice attempt to try to force more users on official desktop-dysfunctional TW builds as testers of "One True Way of SUSE". So, regarding "the development of the openSUSE distributions", since you're are the upstream and demanding from ordinary users having Ph.D. in computer science and endless free time is utterly insane, how about that: 1) Since the damn thing needs free space to even free its space, make it reserve that space for no other reason than to not shit itself when it's time to delete something. 2) Make it checkable and repairable on R/O mount or make your initrd able to check and repair it before mounting anything. Same goes for XFS. Right now they both are never checked at all. 3) Fix it's kernel code or all userspace space-querying software to make it able to figure out its real space utilization. 4) Make automatic snapshot deletion and balancing on potential "not enough space" before throwing it into userspace. Or at least enable your btrfsmaintenance crutches by default. 5) Make snapper defaults realistic and, better yet, make YaST partitioner generate them based on partition/volume parameters. 6) While you're at it, properly present all its features in YaST, especially compression. OR remove it from being default altogether because only those who can handle it need it anyway. PS: I will not even read the replies because I fear for my sanity at this point. I mean, I know I complained about the installer multiple times but only because I think that it's the most egregious example that SUSE leaders are totally out of their minds or cynical to the point of mind-boggling hypocrisy. Either way, feeding such well-written nonsense to the brain in big doses is simply dangerous, one may even start believing it.