[LU-11303] slow chgrp as user when quotas are enabled

Related — Tue, 18 Jan 2022 06:41:39 +0000

Hi,

we have had a user complain that chgrp of a few 1000 file directory tree takes 3x longer than the untar of that data.

it seems likely that this is due to ~~LU-5152~~ which AFAICT introduced code that forces a dt_sync for each chgrp as a user.

is there another way to do this which avoids the dt_sync?

in my experience most HPC sites use secondary (supplementary) groups extensively so that users can be members of several research projects. for various reasons this results in lots of files created with the wrong group for the file's location. as root we periodically trawl the filesystem to correct the group ownership of files to match their physical location (ie. poor mans directory/project quotas), but sometimes users still want to change the group ownerships themselves to "do the right thing", and now this goes a lot slower for them.

so I suppose your expectation that unpriv users doing chgrp is rare is sort of valid because we do most of it manually and sporadically for them as root, but (again, in my experience) because of extensive use of supplementary groups in HPC, users wanting to do a chgrp is perhaps more common than you might think.

project quotas would remove most of our reasons for using chgrp but maybe not all. unfortunately we aren't likely to try any more new things like project quotas any time soon.

BTW it would be good to have lustre test users that had secondary groups in order to find problems like this. I don't see any at the moment. I was looking because I need one to make a regression test case for ~~LU-11227~~ (related to ~~LU-5152~~).

cheers,
robin

Whamcloud Community JIRA

[LU-11303] slow chgrp as user when quotas are enabled