<font size=2 face="sans-serif">Hi Aaron,</font><br><br><font size=2 face="sans-serif">I think the product is designed so that
some inode fields are not propagated among nodes instantly in order to
avoid unnecessary overhead within the cluster. See:</font><br><br><font size=2 face="sans-serif">Exceptions to Open Group technical standards
- IBM Spectrum Scale: Administration and Programming Reference - IBM Spectrum
Scale 4.2 - IBM Knowledge Center</font><br><a href=https://www.ibm.com/support/knowledgecenter/en/STXKQY_4.2.0/com.ibm.spectrum.scale.v4r2.adm.doc/bl1adm_xopen.htm><font size=2 color=blue face="sans-serif">https://www.ibm.com/support/knowledgecenter/en/STXKQY_4.2.0/com.ibm.spectrum.scale.v4r2.adm.doc/bl1adm_xopen.htm</font></a><br><br><font size=2 face="sans-serif">---<br>Keigo Matsubara, Industry Architect, IBM Japan<br>TEL: +81-50-3150-0595, T/L: 6205-0595<br></font><br><br><br><br><font size=1 color=#5f5f5f face="sans-serif">From:      
 </font><font size=1 face="sans-serif">Aaron Knister <aaron.s.knister@nasa.gov></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">2016/07/23 13:47</font><br><font size=1 color=#5f5f5f face="sans-serif">Subject:    
   </font><font size=1 face="sans-serif">[gpfsug-discuss]
inode update delay?</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>I've noticed that there can be a several minute delay
between the time <br>changes to an inode occur and when those changes are reflected in the <br>results of an inode scan. I've been working on code that checks ia_xperm
<br>to determine if a given file has extended acl entries and noticed in <br>testing it that the acl flag wasn't getting set immediately after giving
<br>a file an acl. Here's what I mean:<br><br># cd /gpfsm/dnb32<br><br># date; setfacl -b  acltest*<br>Sat Jul 23 00:24:57 EDT 2016<br><br># date; /usr/lpp/mmfs/samples/util/tsinode /gpfsm/dnb32 | egrep acl | wc
-l<br>Sat Jul 23 00:24:59 EDT 2016<br>5<br><br># date; /usr/lpp/mmfs/samples/util/tsinode /gpfsm/dnb32 | egrep acl | wc
-l<br>Sat Jul 23 00:25:10 EDT 2016<br>5<br><br># date; /usr/lpp/mmfs/samples/util/tsinode /gpfsm/dnb32 | egrep acl | wc
-l<br>Sat Jul 23 00:25:21 EDT 2016<br>0<br><br>I'm a little confused about what's going on here-- is there some kind of
<br>write-behind for inode updates? Is there a way I can cause the cluster
<br>to quiesce and flush all pending inode updates (an mmfsctl suspend and
<br>resume seem to have this effect but I was looking for something a little
<br>less user-visible)? If I access the directory containing the files from
<br>another node via the VFS mount then the update appears immediately in <br>the inode scan. A mere inode scan from another node w/o touching the <br>filesystem mount doesn't necessarily seem to trigger this behavior.<br><br>Thanks!<br><br>-Aaron<br><br>-- <br>Aaron Knister<br>NASA Center for Climate Simulation (Code 606.2)<br>Goddard Space Flight Center<br>(301) 286-2776<br>_______________________________________________<br>gpfsug-discuss mailing list<br>gpfsug-discuss at spectrumscale.org<br></font></tt><a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss"><tt><font size=2>http://gpfsug.org/mailman/listinfo/gpfsug-discuss</font></tt></a><tt><font size=2><br><br></font></tt><br><br><BR>