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. -- Chris Murphy -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org