<div class="socmaildefaultfont" dir="ltr" style="font-family:Arial, Helvetica, sans-serif;font-size:10pt" ><div dir="ltr" >Ryan,</div>
<div dir="ltr" >&nbsp;</div>
<div dir="ltr" >I'm not aware of a direct method to determine whether you have been affected, but in general if you use different subblock sizes in a file system, your system is impacted, and the larger the difference, the higher the impact is. This particular problem only happens when <strong>mmcheckquota</strong> is invoked.</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" data-history-expanded="1" dir="ltr" style="border-left:solid #aaaaaa 2px; margin-left:5px; padding-left:5px; direction:ltr; margin-right:0px" >----- Original message -----<br>From: Ryan Novosielski &lt;novosirj@rutgers.edu&gt;<br>Sent by: gpfsug-discuss-bounces@spectrumscale.org<br>To: gpfsug main discussion list &lt;gpfsug-discuss@spectrumscale.org&gt;<br>Cc:<br>Subject: [EXTERNAL] Re: [gpfsug-discuss] SS 5.0.x and quota issues<br>Date: Mon, May 18, 2020 1:34 PM<br>&nbsp;
<div><font size="2" face="Default Monospace,Courier New,Courier,monospace" >Is there a simple way to tell if we\u2019re currently being affected by this bug?<br><br>We run 5.0.4-1 on the client side and 5.0.3-2.3 on the server side (DSS-G 2.4b I believe it is).<br><br>--<br>____<br>|| \\UTGERS, &nbsp; |---------------------------*O*---------------------------<br>||_// the State | &nbsp; &nbsp; &nbsp; &nbsp; Ryan Novosielski - novosirj@rutgers.edu<br>|| \\ University | Sr. Technologist - 973/972.0922 (2x0922) ~*~ RBHS Campus<br>|| &nbsp;\\ &nbsp; &nbsp;of NJ | Office of Advanced Research Computing - MSB C630, Newark<br>&nbsp;&nbsp; &nbsp; `'<br><br>&gt; On May 18, 2020, at 12:58 PM, Felipe Knop &lt;knop@us.ibm.com&gt; wrote:<br>&gt;<br>&gt; All,<br>&gt; &nbsp;<br>&gt; 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 mmcheckquota would compute quotas incorrectly in file systems where metadata pool and data pool subblocksizes are different.<br>&gt; &nbsp;<br>&gt; &nbsp; Felipe<br>&gt; &nbsp;<br>&gt; ----<br>&gt; Felipe Knop knop@us.ibm.com<br>&gt; GPFS Development and Security<br>&gt; IBM Systems<br>&gt; IBM Building 008<br>&gt; 2455 South Rd, Poughkeepsie, NY 12601<br>&gt; (845) 433-9314 T/L 293-9314<br>&gt; &nbsp;<br>&gt; &nbsp;<br>&gt; &nbsp;<br>&gt; ----- Original message -----<br>&gt; From: Jaime Pinto &lt;pinto@scinet.utoronto.ca&gt;<br>&gt; Sent by: gpfsug-discuss-bounces@spectrumscale.org<br>&gt; To: gpfsug-discuss@spectrumscale.org<br>&gt; Cc:<br>&gt; Subject: [EXTERNAL] Re: [gpfsug-discuss] SS 5.0.x and quota issues<br>&gt; Date: Mon, May 18, 2020 9:56 AM<br>&gt; &nbsp;<br>&gt; So Bob,<br>&gt; 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>&gt;<br>&gt; 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>&gt;<br>&gt; 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>&gt;<br>&gt; 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>&gt;<br>&gt; 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>&gt;<br>&gt; Thanks<br>&gt; Jaime<br>&gt;<br>&gt;<br>&gt; On 5/18/2020 08:59:09, Cregan, Bob wrote:<br>&gt; &gt; Hi,<br>&gt; &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; &gt;<br>&gt; &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; &gt;<br>&gt; &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; &gt;<br>&gt; &gt; We are using user and group quotas in a fileset context.<br>&gt; &gt;<br>&gt; &gt; Thanks<br>&gt; &gt;<br>&gt; &gt;<br>&gt; &gt; *Bob Cregan*<br>&gt; &gt; HPC Systems Analyst<br>&gt; &gt;<br>&gt; &gt; Information &amp; Communication Technologies<br>&gt; &gt;<br>&gt; &gt; Imperial College London,<br>&gt; &gt; South Kensington Campus London, SW7 2AZ<br>&gt; &gt; T: 07712388129<br>&gt; &gt; E: b.cregan@imperial.ac.uk<br>&gt; &gt;<br>&gt; &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;&nbsp;&gt;<br>&gt; &gt;<br>&gt; &gt; _1505984389175_twitter.png @imperialRCS @imperialRSE<br>&gt; &gt;<br>&gt; &gt; 1505983882959_Imperial-RCS.png<br>&gt; &gt;<br>&gt; &gt;<br>&gt; &gt;<br>&gt; &gt; _______________________________________________<br>&gt; &gt; gpfsug-discuss mailing list<br>&gt; &gt; gpfsug-discuss at spectrumscale.org<br>&gt; &gt; <a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss" target="_blank">http://gpfsug.org/mailman/listinfo/gpfsug-discuss</a>&nbsp;&nbsp;<br>&gt; &gt;<br>&gt;<br>&gt; .<br>&gt; .<br>&gt; . &nbsp; &nbsp; &nbsp; &nbsp;************************************<br>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;TELL US ABOUT YOUR SUCCESS STORIES<br>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; <a href="http://www.scinethpc.ca/testimonials" target="_blank">http://www.scinethpc.ca/testimonials</a>&nbsp;&nbsp;<br>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ************************************<br>&gt; ---<br>&gt; Jaime Pinto - Storage Analyst<br>&gt; SciNet HPC Consortium - Compute/Calcul Canada<br>&gt; www.scinet.utoronto.ca - www.computecanada.ca<br>&gt; University of Toronto<br>&gt; 661 University Ave. (MaRS), Suite 1140<br>&gt; Toronto, ON, M5G1M1<br>&gt; P: 416-978-2755<br>&gt; C: 416-505-1477<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;&nbsp;<br>&gt; &nbsp;<br>&gt; &nbsp;<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><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>