New subject: [opensuse-factory] btrfs qgroup concerns

3 Sep 2016

      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 :)
...
2.
https://github.com/kdave/btrfs-progs/commit/637c005ac881a7def923e3f56c9f9285...
Upstream  has performance and stability concerns in the current code.
That commit is two weeks old.
I will quote from that commit
"Signed-off-by: David Sterba "

David is another one of SUSEs btrfs developers, we ARE upstream.
The advice in David's documentation is true. There is a performance
hit and you should only turn it on if you' are using it. We are using
it in snapper, therefore we turn it on and take that hit.
That's not a performance concern, that's good documentation.

And yes, there have been corner cases, and our developers have fixed
them, and will fix them when they're reported. That doesn't mean it's
'unstable', that means there are corner cases.
...
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".
4.4 is the latest upstream LTS Kernel

4.7 is the latest upstream kernel

You have tested 4.7 in tumbleweed, and quoted from commits for 4.7

The current 4.4 Kernel contains many backports from 4.7. It also
contains code which 4.7 has totally changed, so has specific fixes for
4.4 that are nothing to do with the current state in 4.7.

These 4.4 backports+fixes number in the thousands. Many of them were
written by SUSE engineers as part of their work for SLE 12 SP2/Leap
42.2 and then submitted upstream (it's our policy to submit all of our
patches upstream).

In the very unlikely event of upstream not accept a small amount of
our patches, there is also the possibility that OUR 4.4 LTS Kernel
might have some patches and configuration that differs from upstream
vanilla 4.4 LTS.

So, to put it bluntly, everything you tested in 4.7 is irrelevant
unless you prove otherwise. everything you read about the current
upstream development is not conclusive unless you prove otherwise.

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.
-- 
To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org
To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Re: [opensuse-factory] btrfs qgroup concerns

Richard Brown

Sergey Kondakov

Richard Brown

Richard Brown

Per Jessen

Carlos E. R.

Stefan Seyfried

Richard Brown

tags

participants (5)