<div class="socmaildefaultfont" dir="ltr" style="font-family:Arial, Helvetica, sans-serif;font-size:10pt" ><div dir="ltr" >All,</div>
<div dir="ltr" >&nbsp;</div>
<div dir="ltr" >Likely not an answer to these situations, but a fix was introduced in 5.0.4.4 (APAR IJ22894) and 4.2.3.22 (APAR IJ24661) to address a (long-standing) problem where <strong>mmcheckquota</strong> would compute quotas incorrectly in file systems where metadata pool and data pool subblocksizes are different.</div>
<div dir="ltr" >&nbsp;</div>
<div dir="ltr" >&nbsp; Felipe</div>
<div dir="ltr" >&nbsp;</div>
<div dir="ltr" >----<br>Felipe Knop knop@us.ibm.com<br>GPFS Development and Security<br>IBM Systems<br>IBM Building 008<br>2455 South Rd, Poughkeepsie, NY 12601<br>(845) 433-9314 T/L 293-9314<br>&nbsp;</div>
<div dir="ltr" >&nbsp;</div>
<div dir="ltr" >&nbsp;</div>
<blockquote data-history-content-modified="1" dir="ltr" style="border-left:solid #aaaaaa 2px; margin-left:5px; padding-left:5px; direction:ltr; margin-right:0px" >----- Original message -----<br>From: Jaime Pinto &lt;pinto@scinet.utoronto.ca&gt;<br>Sent by: gpfsug-discuss-bounces@spectrumscale.org<br>To: gpfsug-discuss@spectrumscale.org<br>Cc:<br>Subject: [EXTERNAL] Re: [gpfsug-discuss] SS 5.0.x and quota issues<br>Date: Mon, May 18, 2020 9:56 AM<br>&nbsp;
<div><font size="2" face="Default Monospace,Courier New,Courier,monospace" >So Bob,<br>Yes, we too have observed an uncharacteristic lag on the correction of the internal quota accounting on GPFS since we updated from version 3.3 to version 4.x some 7-8 years ago. That lag remains through version 5.0.x as well. And it persisted through several appliances (DDN, G200, GSS, ESS and now DSS-G). In our university environment there is also a lot of data churning, in particular small files.<br><br>The workaround has always been to periodically run mmcheckquota on the top independent fileset to expedite that correction (I have a crontab script that measures the relative size of the in-dought columns on the mmrepquota report, size and inodes, and if either exceeds 2% for any USR/GRP/FILESET I run mmrepquota)<br><br>We have opened supports calls with IBM about this issue in the past, and we never got a solution, to possibly adjust some GPFS configuration parameter, and have this correction done automatically. We gave up.<br><br>And that begs the question: what do you mean by "... 5.0.4-4 ... that has a fix for mmcheckquota"? Isn't mmcheckquota zeroing the in-doubt columns when you run it?<br><br>The fix should be for gpfs (something buried in the code over many versions). As far as I can tell there has never been anything wrong with mmcheckquota.<br><br>Thanks<br>Jaime<br><br><br>On 5/18/2020 08:59:09, Cregan, Bob wrote:<br>&gt; Hi,<br>&gt; &nbsp;&nbsp; &nbsp; &nbsp; At Imperial we&nbsp; have been experiencing an issue with SS 5.0.x and quotas. The main symptom is a slow decay in the accuracy of reported quota usage when compared to the actual usage as reported by "du". This discrepancy can be as little as a few percent and as much as many&nbsp; X100% . We also sometimes see bizarre effects such negative file number counts being reported.<br>&gt;<br>&gt; We have been working with IBM&nbsp; and have put in the latest 5.0.4-4 (that has a fix for mmcheckquota) that we have been pinning our hopes on, but this has not worked.<br>&gt;<br>&gt; Is anyone else experiencing similar issues? We need to try and get an idea if this is an issue peculiar to our set up or a more general SS problem.<br>&gt;<br>&gt; We are using user and group quotas in a fileset context.<br>&gt;<br>&gt; Thanks<br>&gt;<br>&gt;<br>&gt; *Bob Cregan*<br>&gt; HPC Systems Analyst<br>&gt;<br>&gt; Information &amp; Communication Technologies<br>&gt;<br>&gt; Imperial College London,<br>&gt; South Kensington Campus London, SW7 2AZ<br>&gt; T: 07712388129<br>&gt; E: b.cregan@imperial.ac.uk<br>&gt;<br>&gt; W: www.imperial.ac.uk/ict/rcs &lt;<a href="http://www.imperial.ac.uk/ict/rcs" target="_blank">http://www.imperial.ac.uk/ict/rcs</a>&nbsp;&gt;<br>&gt;<br>&gt; _1505984389175_twitter.png @imperialRCS @imperialRSE<br>&gt;<br>&gt; 1505983882959_Imperial-RCS.png<br>&gt;<br>&gt;<br>&gt;<br>&gt; _______________________________________________<br>&gt; gpfsug-discuss mailing list<br>&gt; gpfsug-discuss at spectrumscale.org<br>&gt; <a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss" target="_blank">http://gpfsug.org/mailman/listinfo/gpfsug-discuss</a>&nbsp;<br>&gt;<br><br>.<br>.<br>. &nbsp; &nbsp; &nbsp; &nbsp;************************************<br>&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; TELL US ABOUT YOUR SUCCESS STORIES<br>&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;<a href="http://www.scinethpc.ca/testimonials" target="_blank">http://www.scinethpc.ca/testimonials</a>&nbsp;<br>&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;************************************<br>---<br>Jaime Pinto - Storage Analyst<br>SciNet HPC Consortium - Compute/Calcul Canada<br>www.scinet.utoronto.ca - www.computecanada.ca<br>University of Toronto<br>661 University Ave. (MaRS), Suite 1140<br>Toronto, ON, M5G1M1<br>P: 416-978-2755<br>C: 416-505-1477<br>_______________________________________________<br>gpfsug-discuss mailing list<br>gpfsug-discuss at spectrumscale.org<br><a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss" target="_blank">http://gpfsug.org/mailman/listinfo/gpfsug-discuss</a>&nbsp;</font><br>&nbsp;</div></blockquote>
<div dir="ltr" >&nbsp;</div></div><BR>