Hi All,
On 1 September 2016 at 20:10, Chris Murphy
On Thu, Sep 1, 2016 at 11:52 AM, Ronan Arraes Jardim Chagas
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