Details
-
Bug
-
Resolution: Fixed
-
Minor
-
Lustre 2.10.4
-
None
-
3
-
9223372036854775807
Description
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
Attachments
Issue Links
- is related to
-
LU-12826 Project quotas: users can change project IDs
- Resolved
-
LU-5152 Can't enforce block quota when unprivileged user change group
- Resolved
-
LU-7239 mdd_attr_set() synchronous when it need not be
- Resolved
-
LU-11227 client process hangs when lod_sync accesses deactivated OSTs
- Resolved
-
LU-13176 rename() to another directory should transfer project quota
- Resolved
- is related to
-
LU-12351 quota not enforced on chgrp
- Open
-
LU-13176 rename() to another directory should transfer project quota
- Resolved