phillxnet
October 5, 2018, 6:09pm
2
@nfriedly Hello again.
Yes, it wasnt’ long before that setting appeared that if one disabled quotas on Rockstor managed pools then it broke a whole host of stuff. Took quite a bit of work to make everything ‘quota disabled’ compatible. Not sure if that had lead to some of your issues though. But Rockstor was previously most upset (broken) for disabled quotas. Had to steam on with that one as when we switched to docker-ce it ended up disabling quotas for us, nice. See:
opened 04:45PM - 12 Mar 18 UTC
After moving to docer-ce in stable 3.9.2-3 (pr #1865) it was found that docker-c… e, upon starting (ie on boot or when it's service was switched on) would disable quotas. This at the time was very disruptive to many basic Rockstor functions so a work around was found in:
"rock-ons-root host pool quota disabled by docker-ce" #1872
and implemented in:
"rock-ons-root host pool quota disabled by docker-ce. Fixes #1872" #1873
essentially adding " '--storage-opt', 'btrfs.min_space=1G' " to dockerd's initialization.
This 'work around' effected a re-enabling of quotas by dockerd almost directly after it had initially disabled them, which it still did. This quota cycling of the affected pool on every boot was alleviated some what by improving Rockstor's quota disabled/cycling capabilities under issue:
"improve quotas not enabled behaviour" #1869
and pr:
"improve quotas not enabled behaviour. Fixes #1869" #1874
Given the above recent improvement in quota disabled behaviour a Web-UI selector for quotas / pool was introduced via issues:
"[New feature] Add option to disable BTRFS quota/qgroups" #1592 and "Feature: Quota rebuild script?" #1785
and implemented in pr:
"Add option to disable BTRFS quota-qgroups. Fixes #1592" #1903
So we now entertain the user selectable option of Quotas Disabled. But given that a pool's quota state is remembered by the pool itself and all our existing mechanism observe and are informed by the behaviour we have again surfaced an issue with docker-ce dictating pool quota status.
This, to the issue author, looks to be the same upstream issue as was observed in the first referenced issue above (re-referenced here for ease: https://github.com/docker/for-linux/issues/78).
It is not clear how we are to proceed as currently docker-ce is now dictating the final quota state for the pool that hosts it's rock-ons-root share (subvol). This is inappropriate and not in keeping with btrfs defaults of adopting the last quota stats set, which the rest of Rockstor observes.
A workaround for those wishing to adopt a quota disabled state for a pool currently hosting the rock-ons-root is to re-create their rock-ons-root on another pool (where enabled quotas are acceptable) or potentially to revert the changes in #1873; but the latter would simply have docker-ce dictate that quotas were disabled rather than enabled shortly after boot and again circumvent the user setting (added in #1903) and the btrfs default behaviour of maintaining the last setting requested.
Suggestions welcome: however, in the issue authors opinion, docker-ce should not dictate/hard wire quota status, irrespective of it's initialisation parameters. And as such this is viewed as an upstream bug that can only be addressed upstream.
The graphical disable button does nothing but show current state and enable or disable quotas on the associated pool, ie there is no, non transient, db counterpart component to that setting: the source of truth is the pool quota state. But it took until shortly before that inline edit was added for us to work out the various issues that quota disabled had brought.
Well done, bit of a journey that one, and thanks for sharing your findings.