<font size=2 face="sans-serif">mmapplypolicy uses the inodescan API which
to gain overall speed, bypasses various buffers, caches, locks, ... and
just reads inodes "directly" from disk.</font><br><br><font size=2 face="sans-serif">So the "view" of inodescan
is somewhat "behind" the overall state of the live filesystem
as viewed from the usual Posix APIs, such as stat(2).</font><br><font size=2 face="sans-serif">(Not to worry, all metadata updates
are logged, so in event of a power loss or OS crash, GPFS recovers a consistent
state from its log files...)</font><br><br><font size=2 face="sans-serif">This is at least mentioned in the docs.</font><br><br><font size=2 face="sans-serif">`mmfsctl suspend-write; mmfsctl resume;`
is the only practical way I know to guarantee a forced a flush of
all "dirty" buffers to disk -- any metadata updates before the
suspend will for sure</font><br><font size=2 face="sans-serif">become visible to an inodescan after
the resume. (Classic `sync` is not quite the same...)</font><br><br><font size=2 face="sans-serif">But think about this --- scanning a
"live" file system is always somewhat iffy-dodgy and the result
is smeared over the time of the scan -- if there are any concurrent
changes</font><br><font size=2 face="sans-serif">during the scan your results are imprecise.</font><br><br><font size=2 face="sans-serif">An alternative is to use `mmcrsnapshot`
and scan the snapshot. </font><br><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">07/23/2016 12:46 AM</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>