<font size=2 face="sans-serif">Recall that many years ago we demonstrated
a Billion files scanned with mmapplypolicy in under 20 minutes...<br>And that was on ordinary at the time, spinning disks (not SSD!)...  Granted
we packed about 1000 files per directory and made some other choices that
might not be typical usage....  OTOH storage and nodes have improved
since then...</font><br><br><font size=2 face="sans-serif">SO when you say it takes 60 days to
backup 2 billion files and that's a problem....</font><br><font size=2 face="sans-serif">Like any large computing job, one has
to do some analysis to find out what parts of the job are taking how much
time...</font><br><br><font size=2 face="sans-serif">So... what commands are you using to
do the backup...?</font><br><font size=2 face="sans-serif">What timing statistics or measurements
have you collected?</font><br><br><font size=2 face="sans-serif">If you are using mmbackup and/or mmapplypolicy,
those commands can show you how much time they spend scanning the file
system looking for files to backup AND then how much time they spend copying
the data to backup media.  In fact they operate in distinct phases...
directory scan, inode scan, THEN data copying ... so it's straightforward
to see which phases are taking how much time.</font><br><br><font size=2 face="sans-serif">OH... I see you also say you are using
gpfs_stat_inode_with_xattrs64 -- These APIs are tricky and not a panacea....
That's why we provide you with mmapplypolicy which in fact uses those APIs
in clever, patented ways  -- optimized and honed with years of work....
 </font><br><br><font size=2 face="sans-serif">And more recently, we provided you with
samples/ilm/mmfind -- which has the functionality of the classic unix find
command -- but runs in parallel - using mmapplypolicy.<br>TRY IT on you file system!</font><br><br><br><br><font size=1 color=#5f5f5f face="sans-serif">From:      
 </font><font size=1 face="sans-serif">"Tomasz.Wolski@ts.fujitsu.com"
<Tomasz.Wolski@ts.fujitsu.com></font><br><font size=1 color=#5f5f5f face="sans-serif">To:      
 </font><font size=1 face="sans-serif">"gpfsug-discuss@spectrumscale.org"
<gpfsug-discuss@spectrumscale.org></font><br><font size=1 color=#5f5f5f face="sans-serif">Date:      
 </font><font size=1 face="sans-serif">02/08/2018 05:50 AM</font><br><font size=1 color=#5f5f5f face="sans-serif">Subject:    
   </font><font size=1 face="sans-serif">[gpfsug-discuss]
Inode scan optimization</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><font size=2 face="Calibri">Hello All,</font><br><font size=2 face="Calibri"> </font><br><font size=2 face="Calibri">A full backup of an 2 billion inodes spectrum
scale file system on V4.1.1.16 takes 60 days.</font><br><font size=2 face="Calibri"> </font><br><font size=2 face="Calibri">We try to optimize and using inode scans
seems to improve, even when we are using a directory scan and the inode
scan just for having a better performance concerning stat (using gpfs_stat_inode_with_xattrs64).
With 20 processes in parallel doing dir scans (+ inode scans for stat info)
we have decreased the time to 40 days.</font><br><font size=2 face="Calibri">All NSDs are dataAndMetadata type.</font><br><font size=2 face="Calibri"> </font><br><font size=2 face="Calibri">I have the following questions:</font><br><font size=2 face="Symbol">·         </font><font size=2 face="Calibri">Is
there a way to increase the inode scan cache (we may use 32 GByte)? </font><br><font size=2 face="Courier New">o   </font><font size=2 face="Calibri">Can
we us the “hidden” config parameters</font><br><font size=2 face="Wingdings">§  </font><font size=2 face="Calibri">  iscanPrefetchAggressiveness 2</font><br><font size=2 face="Wingdings">§  </font><font size=2 face="Calibri">  iscanPrefetchDepth 0</font><br><font size=2 face="Wingdings">§  </font><font size=2 face="Calibri">  iscanPrefetchThreadsPerNode 0</font><br><font size=2 face="Symbol">·         </font><font size=2 face="Calibri">Is
there a documentation concerning cache behavior?</font><br><font size=2 face="Courier New">o   </font><font size=2 face="Calibri">if
no, is the  inode scan cache process or node specific?</font><br><font size=2 face="Courier New">o   </font><font size=2 face="Calibri">Is
there a suggestion to optimize the termIno parameter in the gpfs_stat_inode_with_xattrs64()
in such a use case?</font><br><font size=2 face="Calibri"> </font><br><font size=2 face="Calibri">Thanks! </font><br><font size=2 face="Calibri"> </font><br><font size=2 face="Calibri">Best regards,</font><br><font size=2 face="Calibri">Tomasz Wolski</font><tt><font size=2>_______________________________________________<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=mWxVB2lS_snDiYR4E348tnzbQTSuuWSrRiBDhJPjyh8&s=FG9fDxbmiCuSh0cvt4hsQS0bKdGHjI7loVGEKO0eTf0&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=mWxVB2lS_snDiYR4E348tnzbQTSuuWSrRiBDhJPjyh8&s=FG9fDxbmiCuSh0cvt4hsQS0bKdGHjI7loVGEKO0eTf0&e=</font></tt></a><tt><font size=2><br></font></tt><br><br><BR>