On Fri, Sep 2, 2016 at 8:17 PM, Jeff Mahoney <jeffm@suse.com> wrote:
Qgroups are enabled to allow snapper to make better decisions about which snapshots to remove automatically. To do this, we only need the qgroups tracking data. We do *nothing* with automatically adding or enforcing limits using them. In a later post, Chris claims that snapper doesn't do this and in fact uses FIEMAP and INO_LOOKUP.
No, that was in response to Andrei about what 'btrfs filesystem du' is using, not snapper. The implicit question is why snapper can't use the same ioctl 'fi du' is using, instead of qgroups.
He's incorrect[1,2]. The feature request for this is for SLES and not public, but since there is a portion of the community that seems to believe that we're just tossing this out there without any testing and with kind of a "oh neat, a shiny toy" approach -- it might be helpful to know that the feature was first requested 4 years ago and was rejected for 5 SLE releases (service packs and GA releases) before we finally enabled it for SLE12 SP2 (and, as a result, Leap and Tumbleweed.) There is always pressure to release a feature but if it's not ready, we don't do it.
What makes this challenging to accept with 100% confidence, is snapper's long standing defaults instigating enospc problems. Yes, enospc is a file system bug, not asnapper bug. But it unquestionably was adding fuel to the fire in the form of an *extremely* aggressive snapshot creation and retention behavior in the form of hundreds of snapshots. But instead of being recognized as needing toning down, a.) the user was passively blamed by telling them they can just change snapper's configuration, b.) not acknowledging the total lack of use case for so many OS states being retained and for so long; and now c.) enabling quotas silently, just makes it seems like doubling down and papering over previous excesses instead of a simple mea culpa. Further making this challenging to accept at face value is the most recent brfs-progs 4.7.1 available upstream has very conservative language when it comes to quotas: PERFORMANCE IMPLICATIONS When the quotas are turned on, they affect all extent processing, taking a performance hit. It is not recommended to turn on qgroups unless the user intends to actually use them STABILITY STATUS The qgroup implementation has turned out to be quite difficult as it affects the core of the filesystem operation. The users have hit various corner cases over time, eg. wrong accounting or system instability. The situation is gradually improving but currently (4.7) there are still issues found and fixed. I don't see how these notes get recognized if (open)suse is using quota code substantially similar to upstream. Only if your code base is substantially different can you convincingly say you have no performance or stability concerns. Therefore it brings me right back to why snapper can't do things differently? a.) tone down the frequency of snapshots, and/or the retention time/quantity; b.) use the ioctl's being used by btrfs fi du instead of enabling quotas? Why the hard dependency on enabling quotas? It really strikes me as snapper being fundamentally flawed that it can't clean up after itself any better than it does unless quotas are enabled for accounting.
The issue the user ran into was not *at all* caused by qgroups.
I'll take your word for it. However, there are other opinions on the issue of qgroups aside from the one user with a mysterious enospc problem. http://www.spinics.net/lists/linux-btrfs/msg58385.html -- Chris Murphy -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org