On Thu, Sep 1, 2016 at 10:28 AM, Chris Murphy <lists@colorremedies.com> wrote:

On Thu, Sep 1, 2016 at 10:15 AM, Richard Brown <RBrownCCB@opensuse.org> wrote:

...

On 1 September 2016 at 17:57, Chris Murphy <lists@colorremedies.com> wrote:

...

Hi,

Could someone urgently check a default installation of the current Leap beta?

btrfs qgroup show /

It seems at least one user has found in Tumbleweed that Btrfs quotas are enabled by default, and experiencing bogus enospc as a result (actually they're the result of quotas so they aren't entirely bogus).

I don't know how this happened, and I'm actually very curious how it happened. But the priority is to find out if Leap has them enabled by default and if so what's doing that so it can be reverted. It's bad to do this in Tumbleweed, but it's a blocker bug for Leap. It can't ship if quotas are enabled.

Why can't it ship if quotas are enabled?

Quotas should be enabled as part of the new snapper functionality http://snapper.io/2016/05/18/space-aware-cleanup.html

This functionality is expected to ship in SLE 12 SP2 and therefore should also be present in Leap 42.2

Change the plans. This feature is not ready for prime time. It just got it's 3rd rewrite this year. There are still problems. Upstream it's pretty much considered by everyone to be experimental. People who use it almost immediately start having problems. The Btrfs list is full of this.

A user installs Tumbleweed, tried to do a simple build, and gets enospc that most of the time doesn't even give indications that the enospc is related to quotas. It took a f'n week to track down that it was due to quotas. There should be very clear messages that it's a quota being busted, not some generic enospc. That alone is a reason to not ship it in this condition.

Richard, the thread you participated in on this list "Problem with BTRFS in openSUSE Tumbleweed: No space left on device" is the direct result of quotas being enabled. That's the problem. This is the start of the thread: http://www.spinics.net/lists/linux-btrfs/msg57925.html This is the traceback, that after at least a week of screwing around with the problem, finally implicates qgroups: http://www.spinics.net/lists/linux-btrfs/msg58339.html And this was that user's 2nd clean installation with a new file system created each time, so at least in that user's workload, which doesn't seem like an edge case to me, is probably asking for trouble until this is more deeply explored. -- Chris Murphy -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Hi Richard, Em Qui, 2016-09-01 às 18:15 +0200, Richard Brown escreveu:

Why can't it ship if quotas are enabled?

Quotas should be enabled as part of the new snapper functionality http://snapper.io/2016/05/18/space-aware-cleanup.html

This functionality is expected to ship in SLE 12 SP2 and therefore should also be present in Leap 42.2

I'm using Tumbleweed here in a workstation because I need a newer kernel than we have in Leap 42.1. However, since day 1 I had problems with ENOSPC. This started to be very annoying since this machine is supposed to be on 24/7 and sometimes only a reboot fix the ENOSPC. I would be very surprised if a machine with Leap leads to random reboots due to such issues. Actually, I have a server here with Leap 42.1, which also do the builds that usually trigger the problem, that has never shown the problem. And now I see that qgroups is not enabled there. If you are planning to enable qgroups for Leap 42.2, and nothing changes in kernel compared to Tumbleweed, I should advice to strongly consider removing qgroups and postpone this novel snapper feature. Notice that what made my report the bug was when the ENOSPC problem occurred just in the middle of a `zypper dup`, which broke my entire system. I was saved by a snapshot. Best regards, Ronan Arraes -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

So that could be another way around it is to have /home remain on XFS.

I did a fresh install of Tumbleweed last night and /home defaulted to XFS. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Hi All, On 1 September 2016 at 20:10, Chris Murphy <lists@colorremedies.com> wrote:

On Thu, Sep 1, 2016 at 11:52 AM, Ronan Arraes Jardim Chagas <ronisbr@gmail.com> wrote:

...

Hi Richard,

Em Qui, 2016-09-01 às 18:15 +0200, Richard Brown escreveu:

...

Why can't it ship if quotas are enabled?

Quotas should be enabled as part of the new snapper functionality http://snapper.io/2016/05/18/space-aware-cleanup.html

This functionality is expected to ship in SLE 12 SP2 and therefore should also be present in Leap 42.2

I'm using Tumbleweed here in a workstation because I need a newer kernel than we have in Leap 42.1. However, since day 1 I had problems with ENOSPC. This started to be very annoying since this machine is supposed to be on 24/7 and sometimes only a reboot fix the ENOSPC.

I would be very surprised if a machine with Leap leads to random reboots due to such issues. Actually, I have a server here with Leap 42.1, which also do the builds that usually trigger the problem, that has never shown the problem. And now I see that qgroups is not enabled there.

What 'builds' are you doing? Why are you doing them on btrfs? Would it make more sense to do them in a subvolume and therefore immunise yourself entirely from the snapshotting of the root subvolume and the quota there? Would it make more sense to use XFS for your non-system data, like SUSE recommend, like openSUSE implements by default and I would also recommend?

...

If you are planning to enable qgroups for Leap 42.2, and nothing changes in kernel compared to Tumbleweed, I should advice to strongly consider removing qgroups and postpone this novel snapper feature.

I'd like to know where you and Chris get the idea that the Tumbleweed kernel has absolutely anything to do with the Leap kernel. We've been talking about Leap for over a year now. It is a/the hybrid distribution, enterprise core, community packages on top. To put it graphically, you can imagine it like this https://speakerdeck.com/sysrich/open-enterprise-and-open-community-working-t... the kernel, very clearly, is a part of that core. In Leap 42.1 the community, after some debate, decided to deviate from SLE 12 SP1's kernel in the name of hardware ennablement. That is why the 'Shared Core' box in the Leap column is smaller than in the SLE column. That is not the case for Leap 42.2, where the basic rule of thumb has been "if we can take it from SLE 12 SP2, we will take it from SLE 12 SP2" Kernel, systemd, Qt, even userspace parts like GNOME will match in Leap 42.2 and SLE 12 SP2 (in the case of GNOME, that is primarily because SUSE are also jumping their SLE GNOME to exactly where we'd want our Leap GNOME, a clear case study in the 'river flowing both ways' between openSUSE and SUSE). Leap 42.2 is based primarily on SLE 12 SP2 for it's core, and Leap 42.1 for it's community packages. If our maintainers want to update those community packages they have the OPTION of selectively pulling stuff from Tumbleweed into Leap, but as this graph clearly shows with dotted lines, this is not a complete sync, it never should be, as the whole point of Leap is stability (both in terms of 'it works' and 'it doesn't change) over potentially risky or workflow changing alterations. https://speakerdeck.com/sysrich/open-enterprise-and-open-community-working-t... So back to the point here - the Leap 42.2 kernel is the same kernel that will be released in SLE 12 SP2. That means kernel 4.4 with SUSE's Enterprise patches, and will be receiving SUSE's enterprise maintenance updates until Leap moves to something else. This is not the Tumbleweed kernel. It is not the current 4.7 Tumbleweed Kernel. It is not the Kernel you have found your issues with quotas on. It's a distant relation to the Tumbleweed 4.4 Kernel from January, but with a combination of both upstream efforts (4.4 is an upstream LTS kernel) and SUSE's efforts (as part of the aforementioned SLE 12 SP2 work) we're talking about literally tens of thousands of *changelog* entries, never mind how many tens of thousands of actual changes to the actual code of the actual kernel Leap will be using. So, while I appreciate your experience with Tumbleweed may have you concerned, your testing on Tumbleweed is invalid in the context of Leap 42.2. I would request you use the opportunity of the Beta to test the Beta, and if bugs are present, file them in bugzilla.opensuse.org against the Beta. We have no evidence at this time that the quota functionality as we have it in Leap 42.2 is not ready for use, and your opinions, while very passionately stated, are not based on information relevant to Leap 42.2.

...

Notice that what made my report the bug was when the ENOSPC problem occurred just in the middle of a `zypper dup`, which broke my entire system. I was saved by a snapshot.

Yeah none of this is your fault. If you hadn't persevered with the troubleshooting in the face of literally no one having any goddamn idea WTF was going on, we still wouldn't know.

The open question though is whether Tumbleweed defaults to /home also on Btrfs, compared to Leap. Because the previous version of Leap had /home on XFS by default so far fewer users will be impacted by quotas enabled by default if /home is still on XFS. But if/when /home is on Btrfs, it'll be a problem.

So that could be another way around it is to have /home remain on XFS.

Leap 42.2, like all current openSUSE and SLE distributions, defaults to btrfs as / and XFS as /home -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Thu, Sep 1, 2016 at 1:11 PM, Richard Brown <RBrownCCB@opensuse.org> wrote:

What 'builds' are you doing? Why are you doing them on btrfs? Would it make more sense to do them in a subvolume and therefore immunise yourself entirely from the snapshotting of the root subvolume and the quota there?

Would it make more sense to use XFS for your non-system data, like SUSE recommend, like openSUSE implements by default and I would also recommend?

Permission to do something in a GUI installer is by definition that which is supported and recommended, it's just that defaults are more highly recommended. It is untenable to blame the user, even a little, by not using defaults. If you think Btrfs has too many problems for /home, then inhibit the installer from allowing it. A GUI installer is a user advocate. If it betrays the user with bad advice that is the fault of the installer and its development team.

So back to the point here - the Leap 42.2 kernel is the same kernel that will be released in SLE 12 SP2. That means kernel 4.4 with SUSE's Enterprise patches, and will be receiving SUSE's enterprise maintenance updates until Leap moves to something else.

This is not the Tumbleweed kernel. It is not the current 4.7 Tumbleweed Kernel. It is not the Kernel you have found your issues with quotas on.

This is not reassuring, quite the opposite. Quota support isn't even stable in 4.7 let alone 4.4. So what you've just told me is that there is a secret decoder ring in place for the Leap and SLE kernels. I just have no idea whether you're using 4.7 backports to 4.4? Or if you're using some totally different out of tree quota code. So what's going to happen is any Leap user using a Leap kernel comes on the upstream list and people are going to say two things: 1. Disable quotas. 2. Use a vanilla stable or mainline kernel. OR Go to opensuse.org and ask your question their, it's their kernel, their tools, their defaults, their recommendations, and you can get support from them. Because no one upstream has any interest whatsoever understanding Ubuntu, CentOS, RHEL, or openSUSE Leap's secret f'n decoder ring for whatever the hell "4.4" kernel actually means when it comes to *anything* related to Btrfs.

So, while I appreciate your experience with Tumbleweed may have you concerned, your testing on Tumbleweed is invalid in the context of Leap 42.2.

It's only invalid if your quota support in the Leap kernel doesn't come from upstream code being backported. If you're using out of tree code, then you're right. If opensuse is using backports from upstream code I absolutely can extrapolate from a 4.7.x and 4.8.x kernel. People have had problems with that code base, even very recently within the past few days, and Qu is working on that.

I would request you use the opportunity of the Beta to test the Beta, and if bugs are present, file them in bugzilla.opensuse.org against the Beta.

No thanks. I don't have the time. You've received the message, do what you want with it. I've suggested your snapper defaults are crap, you guys don't listen to that, so you just want to push forward with more pathological nonsense. You're papering over the previous bad snapper behaviors with quotas instead of fixing the nutcase snapper defaults. Fine. Live with it. Trust me, if your Tumbleweed or Leap users or Btrfs get a black eye over this decision, I will be far less diplomatic about it. Neither deserve to be treated like guinea pigs just because someone is in too big of a hurry and thinks it's OK to use the community as a public beta testing pool. And even that's too diplomatic because the behavior I'm seeing with quotas doesn't even deserve the "beta" quality label yet.

We have no evidence at this time that the quota functionality as we have it in Leap 42.2 is not ready for use, and your opinions, while very passionately stated, are not based on information relevant to Leap 42.2.

If you think it's ready, put these defaults on your build systems before subjecting your hapless users to it. When anyone asks on linux-btrfs@ about quota support, without fail the list response is, use XFS (or even ext4) because it has stable quota support, Btrfs doesn't. The best way to characterize it, is that it's ready for testing. So if that's what you meant, that's what you should be saying rather than treating me like a moron which is *exactly* what you're doing when you say there's no evidence it's not ready for use, because there is ample evidence upstream. No upstream developer has ever said it's stable, use it. They've only said test it. -- Chris Murphy -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Thu, Sep 1, 2016 at 1:11 PM, Richard Brown <RBrownCCB@opensuse.org> wrote:

Leap 42.2, like all current openSUSE and SLE distributions, defaults to btrfs as / and XFS as /home

By default I'm getting /home as a subvolume on Btrfs. I'm using openSUSE-Leap-42.2-DVD-x86_64-Build0164-Media.iso in a virt-manager VM with a 12GiB qcow2 as backing. screenshot.jpg https://drive.google.com/open?id=0B_2Asp8DGjJ9RnRWNDNTdTVPZGs y2log.gz https://drive.google.com/open?id=0B_2Asp8DGjJ9eHFEM1VGNEtrSWM -- Chris Murphy -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2016-09-03 01:58, Roman Bysh wrote:

I'm pretty sure that the /home subvolume is a bug.

The proposal I got when installing under vmplayer, with a 20 GB virtual disk, was 1 GB swap, and the rest one btrfs single filesystem. On proposal adjustments, the tick for separate /home was Off. I erased that automatic proposal and used my own expert settings instead (ext4), so I can not say what subvolumes it would have applied. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlfKFWYACgkQja8UbcUWM1yotwD/b6rtHrHMZtwHGAnDHnEK5dFy 6aRusPSXiB5LhaozDE8A/1kvkq26mNpH2DtRUIgQ7iIKsl8+0jbcPLc/2E99KmVg =AKgo -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2016-09-03 02:20, Chris Murphy wrote:

It's related to the size of the target. Whether it's a bug or not I can't say, but if the idea is really that /home is recommended to be XFS, then below that minimum size the entire installation should be XFS.

It certainly makes sense to have a single partition when disk space is small, but it doesn't make sense to have it as btrfs (because of space needed by snapshots). I would choose ext4, though. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlfKGKEACgkQja8UbcUWM1xS6gD+JU2ZoXaxFPMLfJhEbCR8j8rW 8LhX2eDdNeIdigQMxBgBAIuV8sTrV34fIAzHT3guhvM/olwjBLiJ+ki7+6C5P0Rq =ZfmF -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Hi Jeff! Thanks for the enlightening e-mail. It was clear that the qgroups were not the root cause of my issue as you said. I can confirm that even without this feature, the bug still happens in the same frequency. I am glad to know a little bit more how things work with SLE and, now, with Leap. Unfortunately, I will also not be able to change my distro from TW to Leap because I need kernel 4.6 at least. But I do have a side question: I understood that SLE and Leap do not seem to have any major problems with qgroups, but, since Tumbleweed use almost a vanilla kernel w.r.t. BTRFS, should it can also be considered stable there? Back to my bug, one thing that **always** happens is that after the discussed problem, the metadata increases **a lot** (I saw something like 80 GiB once). Hence, is there any kind of configuration to fix the minimum metadata size? If it is, do you think that I can get rid of those ENOSPC by fixing a very high limit, such as 300 GiB? Ah! I think I forgot to mention one very important thing: I have been using Tumbleweed+BTRFS on this machine for a very very very long time. I think I installed it just after it changed to the current model. By that time, I was using the same machine but without one peripheral that requires a "new" kernel (HDD, processor, RAM, everything was the same). AFAIK, the first time I saw that problem was this year. So, I think it must be a regression after some kernel / btrfs-progs update. Best regards, Ronan Arraes -- 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 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

On 9/2/16 11:36 PM, Chris Murphy wrote:

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.

Arvin provided the answer in a separate post. What you're not getting is that qgroups is the standard file system method to track extent usage on a subvolume level. In my opinion, this information should be tracked on every file system since it's information *every* user wants. We just don't have good tools to provide it and, ideally, it should be provided using standard tools like 'df.' The biggest current use, for us, is for snapper but it's not the only planned use.

...

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.

You're making a lot of assumptions here which are personal opinions and treating them as concrete fact. The way snapper handles snapshot creation may not be what *you* want to see, but it serves a purpose. The thing is that on a per-snapshot basis, having lots of tightly coupled snapshots doesn't use a ton of disk space. You could have a thousand snapshots taken a second apart and it wouldn't use much more disk space than having two taken a thousand seconds apart unless there was a huge churn in the middle that wasn't reflected in the final state. That's the main benefit of btrfs: snapshots are cheap, both in time spent creating them and in disk space used to store them. It's the divergence between snapshots that takes up the disk space, and so you could have a single snapshot taken 6 months ago and you may have more or less the same amount of space pinned on the file system. So, no, I view your blaming snapper's snapshot policy as a bit of a red herring. It entirely depends on the workload. And your typical root file system doesn't have a very active write/delete workload outside of software updates and /tmp (which we don't snapshot). I'm willing to admit that a Tumbleweed system running a nightly automated 'zypper dup' would be pretty much the pathological case for this, though. That's why it's a default policy and not a hard coded policy. So, moving beyond your assertion that snapper is "extremely aggressive" and on to "not acknowledging the total lack of use case for so many OS states being retained." We have as a primary feature for SLE12, which I believe is also available on Tumbleweed, the ability to select any snapshot and boot from it with the option of rolling your entire system back to that state, with logs, databases, etc excepted. This might not be a feature *YOU* personally want, but it is one that our customers want and use regularly. Taking snapshots as part of system change transactions is a pretty obvious place to do that. Similarly, time-based snapshots are pretty standard as well. And lastly, your assertion that we're "doubling down" and "papering over" mistakes rings pretty hollow in the context I've outlined above.

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.

We have some concerns but not in the vein of stability. Any quota system has performance overhead. It's the nature of tracking more information taking more time/space than not tracking it. In the qgroup case, there does exist a significant performance issue when the number of backreferences to a single extent grows too large -- they're tracked as a list and there's an O(n^2) algorithm in the middle of it. Fortunately, that isn't a case many users hit on live systems and I'm working on a fix for it. So, maybe I haven't convinced you, but I've stated our testing regimen and our belief that it's stable. Ultimately, I'm the one who has to respond to bug reports against them and deal with any fallout, and I sleep pretty well.

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.

Again, Arvin explained the reasoning for using qgroups. What you seem to be missing is that this *is* snapper cleaning up after itself using information the file system can provide efficiently. Unused disk space is wasted disk space, and if you say you want your file system to have 30% head space above any snapshots, we need the allocation information to know how to honor that guarantee. Removing snapshots until we were under 30% is pretty frustrating for the user when you can't tell them ahead of time which snapshots are getting tossed.

...

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

Yep, that's an opinion alright. Well spotted. -Jeff -- Jeff Mahoney SUSE Labs

Ronan Arraes Jardim Chagas writes:

I will use this thread to ask something. In my laptop (a different machine of that in which I am seeing the ENOSPC problem), sometimes my

That's the rebalance part of the btrfs maintenance scripts.

In this case, I do not want to disable quotas because in this laptop I can test features and help fix bugs. Can anyone tell me if this behavior is normal? I'm using a SSD here.

I think it is, although it would surely be welcome if it didn't freeze the machine for some seconds. Unless you see the tell-tale activity in the load monitor you're likely to think that the machine has crashed. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf microQ V2.22R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org