OK
More info:
Users can apply the 'sg group1' or 'sq group2' command from a shell or
script to switch the group mask from that point on, and dodge the
quota that may have been exceeded on a group.
However, as the group owner or other member of the group on the limit,
I could not find a tool they can use on their own to find out who
is(are) the largest user(s); 'du' takes too long, and some users don't
give read permissions on their directories.
As part of the puzzle solution I have to come up with a root wrapper
that can make the contents of the mmrepquota report available to them.
Jaime
Quoting "Buterbaugh, Kevin L" <[email protected]>:
Hi Jaime,
Thank you sooooo much for doing this and reporting back the results!
They?re in line with what I would expect to happen. I was going
to test this as well, but we have had to extend our downtime until
noontime tomorrow, so I haven?t had a chance to do so yet. Now I
don?t have to? ;-)
Kevin
On Aug 4, 2016, at 10:59 AM, Jaime Pinto
<[email protected]<mailto:[email protected]>> wrote:
Since there were inconsistencies in the responses, I decided to rig
a couple of accounts/groups on our LDAP to test "My interpretation",
and determined that I was wrong. When Kevin mentioned it would mean
a bug I had to double-check:
If a user hits the hard quota or exceeds the grace period on the
soft quota on any of the secondary groups that user will be stopped
from further writing to those groups as well, just as in the primary
group.
I hope this clears the waters a bit. I still have to solve my puzzle.
Thanks everyone for the feedback.
Jaime
Quoting "Jaime Pinto"
<[email protected]<mailto:[email protected]>>:
Quoting "Buterbaugh, Kevin L"
<[email protected]<mailto:[email protected]>>:
Hi Sven,
Wait - am I misunderstanding something here? Let?s say that I have
?user1? who has primary group ?group1? and secondary group
?group2?. And let?s say that they write to a directory where the
bit on the directory forces all files created in that directory to
have group2 associated with them. Are you saying that those files
still count against group1?s group quota???
Thanks for clarifying?
Kevin
Not really,
My interpretation is that all files written with group2 will count
towards the quota on that group. However any users with group2 as the
primary group will be prevented from writing any further when the
group2 quota is reached. However the culprit user1 with primary group
as group1 won't be detected by gpfs, and can just keep going on writing
group2 files.
As far as the individual user quota, it doesn't matter: group1 or
group2 it will be counted towards the usage of that user.
It would be interesting if the behavior was more as expected. I just
checked with my Lustre counter-parts and they tell me whichever
secondary group is hit first, however many there may be, the user will
be stopped. The problem then becomes identifying which of the secondary
groups hit the limit for that user.
Jaime
On Aug 3, 2016, at 11:35 AM, Sven Oehme
<[email protected]<mailto:[email protected]><mailto:[email protected]>>
wrote:
Hi,
quotas are only counted against primary group
sven
On Wed, Aug 3, 2016 at 9:22 AM, Jaime Pinto
<[email protected]<mailto:[email protected]><mailto:[email protected]>>
wrote:
Suppose I want to set both USR and GRP quotas for a user, however
GRP is not the primary group. Will gpfs enforce the secondary group
quota for that user?
What I mean is, if the user keeps writing files with secondary
group as the attribute, and that overall group quota is reached,
will that user be stopped by gpfs?
Thanks
Jaime
************************************
TELL US ABOUT YOUR SUCCESS STORIES
http://www.scinethpc.ca/testimonials
************************************
---
Jaime Pinto
SciNet HPC Consortium - Compute/Calcul Canada
www.scinet.utoronto.ca<http://www.scinet.utoronto.ca><http://www.scinet.utoronto.ca/> -
www.computecanada.org<http://www.computecanada.org><http://www.computecanada.org/>
University of Toronto
256 McCaul Street, Room 235
Toronto, ON, M5T1W5
P: 416-978-2755<tel:416-978-2755>
C: 416-505-1477<tel:416-505-1477>
----------------------------------------------------------------
This message was sent using IMP at SciNet Consortium, University of Toronto.
_______________________________________________
gpfsug-discuss mailing list
gpfsug-discuss at spectrumscale.org<http://spectrumscale.org>
http://gpfsug.org/mailman/listinfo/gpfsug-discuss
************************************
TELL US ABOUT YOUR SUCCESS STORIES
http://www.scinethpc.ca/testimonials
************************************
---
Jaime Pinto
SciNet HPC Consortium - Compute/Calcul Canada
www.scinet.utoronto.ca<http://www.scinet.utoronto.ca> -
www.computecanada.org<http://www.computecanada.org>
University of Toronto
256 McCaul Street, Room 235
Toronto, ON, M5T1W5
P: 416-978-2755
C: 416-505-1477
----------------------------------------------------------------
This message was sent using IMP at SciNet Consortium, University of Toronto.
_______________________________________________
gpfsug-discuss mailing list
gpfsug-discuss at spectrumscale.org<http://spectrumscale.org>
http://gpfsug.org/mailman/listinfo/gpfsug-discuss
?
Kevin Buterbaugh - Senior System Administrator
Vanderbilt University - Advanced Computing Center for Research and Education
[email protected]<mailto:[email protected]> -
(615)875-9633
************************************
TELL US ABOUT YOUR SUCCESS STORIES
http://www.scinethpc.ca/testimonials
************************************
---
Jaime Pinto
SciNet HPC Consortium - Compute/Calcul Canada
www.scinet.utoronto.ca - www.computecanada.org
University of Toronto
256 McCaul Street, Room 235
Toronto, ON, M5T1W5
P: 416-978-2755
C: 416-505-1477
----------------------------------------------------------------
This message was sent using IMP at SciNet Consortium, University of Toronto.
_______________________________________________
gpfsug-discuss mailing list
gpfsug-discuss at spectrumscale.org
http://gpfsug.org/mailman/listinfo/gpfsug-discuss
