<font size=2 face="sans-serif">Read the doc again.  Specify both

-g and -N options on the command line to get fully parallel directory and

inode/policy scanning.</font><br><br><font size=2 face="sans-serif">I'm curious as to what you're trying

to do with THRESHOLD(0,100,0)    ... Perhaps premigrate everything

(that matches the other conditions)?<br></font><br><font size=2 face="sans-serif">You are correct about</font><br><tt><font size=2>I] 2017-09-12@21:20:44.155 Parallel-piped sort and

policy evaluation. 0 files scanned. (...) [I] 2017-09-12@21:24:14.672 Piped sorting and candidate file choosing.

0 records scanned.<br></font></tt><br><font size=2 face="sans-serif">If you don't see messages like that,

you did not specify both -N and -g.</font><br><br><br><br><font size=1 color=#5f5f5f face="sans-serif">From:      

 </font><font size=1 face="sans-serif">valdis.kletnieks@vt.edu</font><br><font size=1 color=#5f5f5f face="sans-serif">To:      

 </font><font size=1 face="sans-serif">gpfsug-discuss@spectrumscale.org</font><br><font size=1 color=#5f5f5f face="sans-serif">Date:      

 </font><font size=1 face="sans-serif">09/13/2017 08:19 PM</font><br><font size=1 color=#5f5f5f face="sans-serif">Subject:    

   </font><font size=1 face="sans-serif">[gpfsug-discuss]

mmapplypolicy run time weirdness..</font><br><font size=1 color=#5f5f5f face="sans-serif">Sent by:    

   </font><font size=1 face="sans-serif">gpfsug-discuss-bounces@spectrumscale.org</font><br><hr noshade><br><br><br><tt><font size=2>So we have a number of very similar policy files that

get applied for file<br>migration etc. And they vary drastically in the runtime to process, apparently<br>due to different selections on whether to do the work in parallel.<br><br>Running a set of rules with 'mmapplypolicy -I defer' that look like this:<br><br>RULE 'VBI_FILES_RULE' MIGRATE FROM POOL 'system'<br>THRESHOLD(0,100,0)<br>WEIGHT(FILE_SIZE)<br>TO POOL 'VBI_FILES'<br>FOR FILESET('vbi')<br>WHERE (mb_allocated >= 8)<br><br>for 10 filesets can scan 325M directory entries in 6 minutes, and sort

and<br>evaluate the policy in 3 more minutes.<br><br>However, this takes a bit over 30 minutes for the scan and another 20 for<br>sorting and policy evaluation over the same set of filesets:<br><br>RULE 'VBI_FILES_RULE' LIST 'pruned_files'<br>THRESHOLD(90,80)<br>WEIGHT(FILE_SIZE)<br>FOR FILESET('vbi')<br>WHERE (mb_allocated >= 8)<br><br>even though the output is essentially identical.  Why is LIST so much

more<br>expensive than 'MIGRATE" with '-I defer'?        

          I could understand if

I had an<br>expensive SHOW clause, but there isn't one here (and a different policy

that I<br>run that *does* have a big SHOW clause takes almost the same amount of

time as the minimal LIST).... I'm thinking that it has *something* to do with the MIGRATE job outputting: [I] 2017-09-12@21:20:44.155 Parallel-piped sort and policy evaluation.

0 files scanned. (...) [I] 2017-09-12@21:24:14.672 Piped sorting and candidate file choosing.

0 records scanned.<br><br>while the LIST job says:<br><br>[I] 2017-09-12@13:58:06.926 Sorting 327627521 file list records.<br>(...)<br>[I] 2017-09-12@14:02:04.223 Policy evaluation. 0 files scanned.<br><br>(Both output the same message during the 'Directory entries scanned: 0.'<br>phase, but I suspect MIGRATE is multi-threading that part as well, as it<br>completes much faster).<br><br>What's the controlling factor in mmapplypolicy's decision whether or<br>not to parallelize the policy?<br>_______________________________________________<br>gpfsug-discuss mailing list<br>gpfsug-discuss at spectrumscale.org<br></font></tt><a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__gpfsug.org_mailman_listinfo_gpfsug-2Ddiscuss&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=cvpnBBH0j41aQy0RPiG2xRL_M8mTc1izuQD3_PmtjZ8&m=SGbwD3m5mZ16_vwIFK8Ym48lwdF1tVktnSao0a_tkfA&s=sLt9AtZiZ0qZCKzuQoQuyxN76_R66jfAwQxdIY-w2m0&e="><tt><font size=2>https://urldefense.proofpoint.com/v2/url?u=http-3A__gpfsug.org_mailman_listinfo_gpfsug-2Ddiscuss&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=cvpnBBH0j41aQy0RPiG2xRL_M8mTc1izuQD3_PmtjZ8&m=SGbwD3m5mZ16_vwIFK8Ym48lwdF1tVktnSao0a_tkfA&s=sLt9AtZiZ0qZCKzuQoQuyxN76_R66jfAwQxdIY-w2m0&e=</font></tt></a><tt><font size=2><br><br></font></tt><br><br><BR>