Qgroup error in Rockstor log

Having read this post: Repeated qgroup error in Rockstor Log

I now realize that I don’t need to care about the message (other than as clutter). There was a reference in there to needing to do some cleanup in how Rockstor handles re-enabling quotas. I would like to re-enable quotas for this pool (not the root pool) simply to clear the clutter. Is there a concern with doing so, or just some dissatisfaction with how the quota groups are recreated?

I’m running v4.0.4, stable updates.

P.S., I also now realize that Geoff and I have the same toaster - it causes us to get bored and read logs.

2 Likes

@wdc Hello again.
I can chip in re:

No specific concern, we just have work to do there for tallying properly. Keep in mind it can take quit a few minutes to re-build what is required. You can always disable later if the advantages don’t win out on the performance hit. You can enable via Web-UI (preferred) or via command line. Rockstor’s quota group is 2015 in case you fancy taking a look at what is created.

Note that we don’t enforce quotas as of yet. It just helps with seeing the various space used.

Hope that helps.

Oh and keep in mind some old hacks we had to do with our early elrepo/CentOS kernels that are still in place. For example in:


I had to do the following:

for which we have the following issue:

That was painful to have to submit but at the time quotas were is a far worse shape and it was the only way I had found for them to actually do what they were told, i.e. to get them to enable.

But other than that it’s just a slightly basic/nieve management that may now be quite dated. For instance back when we last worked on our side of qoutas they had no internal management for auto delete I think it was. So we will likely have more log spam as well as we try to tidy up what now tidies itself up. So yes, some work to do and some catch up but it’s basically sound on simple arrangements.

And if you find that removing one of those enable lines in your own instance now manages to enable disable enable quotas just fine then feel free to create a pull request against that issue with details of the testing you did to ensure it is now not needed to have such an obtuse piece of code in play still. But keep in mind that disable is almost instant and enable is potentially quit time consuming as the entire pool’s metadata has to be re-scanned. And during this re-scan the quotas are in a limbo state which also confused some of our code. I think our code is mostly robust to this quota ‘phase transition’ now however.

I think the pull request created as a result of that forum thread:

was the most recent quota update I’ve done.

Hope that helps.

1 Like

It certainly helps.
It may be a bit before I do a pull request - I’m not a developer; my career has been in non-dev areas. Anyway, Rockstor is fun and and I may start digging into the code, so I appreciate that snip as a starting point.

1 Like