Details
-
Bug
-
Resolution: Unresolved
-
Minor
-
None
-
None
-
None
-
3
-
9223372036854775807
Description
On today's master, if group quotas are on and a normal user creates files as one group then does a chgrp to a second one, group quotas are not enforced at all for the second group (inode or block).
LU-5152 fixed this issue at some point with 8a71fd5061 ("LU-5152 quota: enforce block quota for chgrp"), but 7b46ff54afb23 ("LU-5152 quota: disable sync chgrp to OSTs") broke the fix - reverting that commit makes chgrp fail with EDQUOT as expected but the patch was introduced because of some deadlock between OST and MDT so we cannot just revert it.
I stumbled into this again because we have quite a few users that are over quota on our long-term filesystems and I believe the reason to be... rsync.
Our users create their files in a scratch, then rsync -a their files over to the longer term FS; rsync will create the files under their primary group then chgrp it, letting them make more files despite having long overrun the limits. (we normally have the group sticky bit set so files should be created with the correct group right away, I need to look a bit more into this, but anyway...)
Splitting this into two sides:
* inode quota: that is enforced directly by MDTs so should possible to re-introduce synchronous check without deadlocks? Frankly speaking this is the most important part for me.
* block quota: I can imagine this will be difficult to fix properly, especially wrt. performance, but we don't really need a precise limit. As a thought, it might be possible to not do this synchronously but just check if the group already is over quota somehow and deny further user-induced chgrps in this case? I don't really know if MDTs already are aware of anything on this side, but since they should be responsible to distribute qunits to osts I believe they should?
( and third point: add tests for this!)
Thanks,
Dominique
Attachments
Issue Links
- is related to
-
-
- Resolved
-