Re: [opensuse-factory] btrfs quotas enabled by default
On Thu, Sep 1, 2016 at 3:21 PM, Matthias G. Eckermann <mge@suse.com> wrote:
Chris,
I think, you are mixing two things, as also Richard pointed out:
1. SLE 12 SP2 / LEAP 42.2 versus upstream/Tumbleweed.
SLE 12 SP2 / LEAP 42.2 have a hardened (and less feature rich) btrfs implementation.
Stop being coy and tell me exactly what quota code base you guys are using in the 4.4 kernel you're shipping for Leap. Are you using upstream backports up to and including 4.7? Or 4.8? Or are you using something else and if so what is it? Because that matters. Right now the upstream code is not ready for production use, the upstream position has been it's ready for testing. If your policy is to subject your Leap users to testing substantially changing code (I've lost count how many quota patches have even come in the last month), you're obligated to tell them. Not silently opt them in.
SUSE is actively participating in making subvolume quotas more robust for use by snapper.
And that's very generous but it doesn't make either the snapper defaults, or silently enabling quota support appropriate. 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.
2. Depending where you go the manpage from, it is either from and for upstream (and thus true) or you found a bug in the manpage for LEAP 42.2 / SLE 12 SP2. In that case, please open a bug report.
Well the only way you get away with that is if you're using an out of tree branch of code for quotas. *shrug* Because the two previous attempts are dead upstream code. And the current code, as I said, is too new and not ready for production and comes with the warnings I've copied from upstream. So just taking out the warnings doesn't make it stable, you know? 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. -- Chris Murphy -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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
On Thu, Sep 1, 2016 at 5:25 PM, Simon Lees <sflees@suse.de> 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. -- Chris Murphy -- 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 <sflees@suse.de> 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
Отправлено с iPhone
2 сент. 2016 г., в 1:17, Chris Murphy <lists@colorremedies.com> написал(а):
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 Fri, Sep 2, 2016 at 12:37 AM, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
Отправлено с iPhone
2 сент. 2016 г., в 1:17, Chris Murphy <lists@colorremedies.com> написал(а):
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?
It does not rely on quotas being on, it uses BTRFS_IOC_INO_LOOKUP and FS_IOC_FIEMAP. It works on directories and subvolumes (and thus snapshots). -- Chris Murphy -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (4)
-
Andrei Borzenkov -
Chris Murphy -
Jeff Mahoney -
Simon Lees