<div dir="ltr">can you please share the entire command line you are using ? <div>also gpfs version, mmlsconfig output would help as well as if this is a shared storage filesystem or a system using local disks. </div><div><br></div><div>thx. Sven</div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Sep 13, 2017 at 5:19 PM <<a href="mailto:valdis.kletnieks@vt.edu">valdis.kletnieks@vt.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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<br>
the minimal LIST)....<br>
<br>
I'm thinking that it has *something* to do with the MIGRATE job outputting:<br>
<br>
[I] 2017-09-12@21:20:44.155 Parallel-piped sort and policy evaluation. 0 files scanned.<br>
(...)<br>
[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 <a href="http://spectrumscale.org" rel="noreferrer" target="_blank">spectrumscale.org</a><br>
<a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss" rel="noreferrer" target="_blank">http://gpfsug.org/mailman/listinfo/gpfsug-discuss</a><br>
</blockquote></div>