Deleting original share after cloning it breaks quotas

Bugs
1

Hi all,
new Rockstor user here and very enthusiast about it.

I have encountered a bug while trying to rename a share (*). Rockstor version is 4.1.0.

My steps are the following:

  • clone share A to B;
  • delete share A.
    Apparently, this breaks the quota system for the entire pool. The Rockstor UI would report the pool quotas as “disabled” and any attempt to enable them would silently fail.

I think the problem is that the qgroup associated with the share is not deleted. I solved it by destroying the qgroup with the btrfs CLI.

I will be happy to provide more info and/or do more tests if needed.

(*) I found out afterwards that the preferred way to rename a share is to actually use mv from the CLI.

3 Likes
2

@maxlnc Thanks for the nice clean report. Much appreciated.

Yes, our qgroup / quotas stuff is definitely in need of some more attention. And your reported findings likely trigger a limitation we still have in that area.

Would you mind creating an issue here:
https://github.com/rockstor/rockstor-core/issues

With your findings, i.e. the reproducer and your resulting work-around.

Any further investigation is always welcome. It may well help to turn on DEBUG logging via:

/opt/rockstor/bin/debug-mode on

you should then get a lot more details in the following log:

/opt/rockstor/var/log/rockstor.log

You could add your finding against the issue you create with your reproducer for throwing the quotas in the first place.

That may help with seeing where our failure lies. There is definitely some important work left to do though on quotas. And we still don’t enforce them and maybe we could begin to do this soon. They have just had such an impact on performance for a goodly number of years now that they are often turned off for performance reasons.

Yes, share (btrfs subvolume) rename from within the Web-UI is a long standing feature request. And as you see from the last comment in your sited issue, we have an issue open for it. All in good time however - hopefully.

Thanks again for your feedback and for sharing your fix/workaround, and do consider creating that issue and having a go at tracking it down. Always good to have folks helping where-ever they can. Plus your finding of that reproducer is super helpful for exploring what the issue is and proving any fix that may be proposed.

Hope that helps.

3 Likes