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