On 09/02/2016 07:47 AM, Chris Murphy wrote:

So please elucidate the list on exactly what code base you guys are using for quotas. If you're saying the warnings don't apply to your implementation then you guys are using something remarkably different and you need to tell us what that is or you do not get to sit there and claim this is a community project.

Given that the right people are probably sleeping or close too now, i'll remind you that you can look at openSUSE's kernel source code in the following locations. https://build.opensuse.org/package/show/openSUSE:Leap:42.2/kernel-default https://github.com/openSUSE/kernel https://github.com/openSUSE/kernel-source (Make sure you get the right branches for the git based one). -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adeliade Australia, UTC+9:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B

Отправлено с iPhone

2 сент. 2016 г., в 1:17, Chris Murphy написал(а):

And you don't even need quota support to do what you want with snapper. For a while now there's been a btrfs ioctl to do pretty much what "btrfs fi du" does to show what is unique and what is shared, per subvolume so you can figure out from that what space is being used or is available rather than enabling quotas.

I had impression that it relies on quota being on, otherwise where it gets information from? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 9/1/16 7:39 PM, Chris Murphy wrote:

On Thu, Sep 1, 2016 at 5:25 PM, Simon Lees wrote:

...

On 09/02/2016 07:47 AM, Chris Murphy wrote:

...

So please elucidate the list on exactly what code base you guys are using for quotas. If you're saying the warnings don't apply to your implementation then you guys are using something remarkably different and you need to tell us what that is or you do not get to sit there and claim this is a community project.

Given that the right people are probably sleeping or close too now, i'll remind you that you can look at openSUSE's kernel source code in the following locations.

https://build.opensuse.org/package/show/openSUSE:Leap:42.2/kernel-default https://github.com/openSUSE/kernel https://github.com/openSUSE/kernel-source

(Make sure you get the right branches for the git based one).

No, I'm not going to do that and it's inappropriate to even suggest it. The people who actually understand the code need to answer the question. They are the ones claiming their quota code is stable and production ready, the burden is on them to prove it, not for me to prove a negative. I'm not spending 1 f'n hour, let alone the likely 20 hours it would take me to look over hundreds to thousands of backports to find out what you guys have done, that compels you to claim your stuff is stable when upstream code is not there yet.

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. -Jeff -- Jeff Mahoney SUSE Labs