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