[gpfsug-discuss] inode update delay?
Keigo Matsubara
MKEIGO at jp.ibm.com
Sun Jul 24 03:31:05 BST 2016
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 <aaron.s.knister at nasa.gov>
To: <gpfsug-discuss at spectrumscale.org>
Date: 2016/07/23 13:47
Subject: [gpfsug-discuss] inode update delay?
Sent by: gpfsug-discuss-bounces at spectrumscale.org
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20160724/bfdd46f7/attachment-0002.htm>
More information about the gpfsug-discuss
mailing list