<div class="socmaildefaultfont" dir="ltr" style="font-family:Arial, Helvetica, sans-serif;font-size:10pt" ><div dir="ltr" >Ryan,</div>
<div dir="ltr" > </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" > </div>
<div dir="ltr" >  Felipe</div>
<div dir="ltr" > </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> </div>
<div dir="ltr" > </div>
<div dir="ltr" > </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 <novosirj@rutgers.edu><br>Sent by: gpfsug-discuss-bounces@spectrumscale.org<br>To: gpfsug main discussion list <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 1:34 PM<br> 
<div><font size="2" face="Default Monospace,Courier New,Courier,monospace" >Is there a simple way to tell if we’re 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,   |---------------------------*O*---------------------------<br>||_// the State |         Ryan Novosielski - novosirj@rutgers.edu<br>|| \\ University | Sr. Technologist - 973/972.0922 (2x0922) ~*~ RBHS Campus<br>||  \\    of NJ | Office of Advanced Research Computing - MSB C630, Newark<br>     `'<br><br>> On May 18, 2020, at 12:58 PM, Felipe Knop <knop@us.ibm.com> wrote:<br>><br>> All,<br>>  <br>> 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>>  <br>>   Felipe<br>>  <br>> ----<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>>  <br>>  <br>>  <br>> ----- Original message -----<br>> From: Jaime Pinto <pinto@scinet.utoronto.ca><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>>  <br>> 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>> > Hi,<br>> >        At Imperial we  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  X100% . We also sometimes see bizarre effects such negative file number counts being reported.<br>> ><br>> > We have been working with IBM  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>> ><br>> > 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>> ><br>> > We are using user and group quotas in a fileset context.<br>> ><br>> > Thanks<br>> ><br>> ><br>> > *Bob Cregan*<br>> > HPC Systems Analyst<br>> ><br>> > Information & Communication Technologies<br>> ><br>> > Imperial College London,<br>> > South Kensington Campus London, SW7 2AZ<br>> > T: 07712388129<br>> > E: b.cregan@imperial.ac.uk<br>> ><br>> > W: www.imperial.ac.uk/ict/rcs <<a href="http://www.imperial.ac.uk/ict/rcs" target="_blank">http://www.imperial.ac.uk/ict/rcs</a>  ><br>> ><br>> > _1505984389175_twitter.png @imperialRCS @imperialRSE<br>> ><br>> > 1505983882959_Imperial-RCS.png<br>> ><br>> ><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>  <br>> ><br>><br>> .<br>> .<br>> .        ************************************<br>>            TELL US ABOUT YOUR SUCCESS STORIES<br>>           <a href="http://www.scinethpc.ca/testimonials" target="_blank">http://www.scinethpc.ca/testimonials</a>  <br>>           ************************************<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>  <br>>  <br>>  <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> <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> </font><br> </div></blockquote>
<div dir="ltr" > </div></div><BR>