-
Notifications
You must be signed in to change notification settings - Fork 138
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
improve quotas not enabled behaviour #1869
Comments
After enabling debug on the example system that displays this issue as detailed in #1867 via:
we have the following:
|
post the following command:
we have:
|
enable_quota(pool) called:
The current suspicion is that we have a quota anomaly on certain pool instances where quota enabled status, such as is enacted upon pool creation, does not stick. Ie. after a reboot the pool has quotas disabled which is not currently supported in Rockstor: with the consequent limitations as noted in this issue. As such this issue may contain relevant info for issue #1592. |
My current thinking on this issue is that we have a quota status not sticking issue on certain pool instances as my understanding is that Rockstor relies on the pool / subvols to maintain their quota status (enabled / disabled) over a reboot where as in the instances noted in this issue that is not happening: hence my recent links to plans to support disabling quotas or functioning with quotas disabled which we currently don't. |
@schakrava I have found the following that may tie our disabled quotas to the recent docker update: Looks like a likely candidate to me. |
I have transitioned this issue to improving our 'quota disabled' behaviour given we now have the culprit: I intend to open a more focused issue on "rock-ons-root pool quota disabled by docker-ce" in the near future. |
Enhancement of quota groups management in progress. Pull request to follow. |
Final testing and code tidy in progress. |
Please update the following forum thread with this issues resolution: |
Thanks for putting down all the details @phillxnet , very helpful! We must(I really need to prioritize to do this myself) address the hard dependency on quotas in Rockstor. We need to investigate the current state of btrfs-quotas feature-set and perhaps let the user disable/enable quotas entirely or on per pool basis and also, as you indicated above, reflect the current quota enforcement to the user where it's appropriate. |
@schakrava Yes, bar the size enforcement and usage reporting the code associated with this issue (pull request soon) seems to allow for all features I've tested so far to function with quotas disabled. Trying to work towards #1592 that we have had for a while. I'll get this code in soon for review as it's so far successfully managed to re-make pqgroups with multiple successive quota disable / enable cycles. All pool quota state UI elements have been fairly aggressively tested it as I've been using it during the dev of the pqgroup management improvements. |
Uses the existing -1/-1 default for pqgoups to represent an unset state for the share.pqgroup and adds an active return to this value whenever quotas are deemed to be disabled. Pqgroup setup is moved from the bootstrap process into the import_shares / shares refresh section. This allows for live setting / resetting of pqgroups via the regular share re-fresh process. Pool.quotas_enabled and share.pqgroup_exist properties are added and all used low level quota actions are adjusted to catch, log, and ignore a quota disabled state. Additionally active pqgroup assignment is added to share resize and share refresh procedures which aid in returning to existence the expected native 2015/n pqgroups and their relationship to the auto generated 0/n qgroups as whenever quotas are disabled all this info (var the 0/n) is lost. UI elements are added in pool and share focused pages to indicate a live status for the associated pool quotas enabled status.
…ed_behaviour improve quotas not enabled behaviour. Fixes #1869
Under certain as yet undetermined circumstances quotas can become disabled. One consequence of this was a failure to mount the related shares upon the following boot / reboot (addressed in issue #1867 and related pr #1868). However there are additional consequences for running with a pool / subvol that has quotas not enabled. These include:
[ ] Size reporting of the affected subvols is reported as 0 bytes.The text was updated successfully, but these errors were encountered: