On Fri, Jun 29, 2018 at 12:25 PM, Vijay Bellur <vbellur@xxxxxxxxxx> wrote:
On Wed, Jun 27, 2018 at 10:15 PM Raghavendra Gowdappa <rgowdapp@xxxxxxxxxx> wrote:All,Thoughts?
There is a requirement in write-behind where during readdirp we may have to invalidate iatts/stats of some of the children of the directory [1]. For lack of better alternatives I added a dentry list to parent inode which contains all children that've been linked (through lookup or readdirp on directory). I myself am not too comfortable with this solution as it might eat up significant memory for large directories.Reading [2] makes me wonder if write-behind is the appropriate place for this change. Shouldn't md-cache be made aware of inode generations or something similar?
Both are independent fixes and cater to different issues. The fix for [2] is at https://review.gluster.org/20410
The patch which is subject of this mail thread tries to address stat consistency when readdirp is done on a directory containing files having cached writes. If readdirp happen to fetch dentries of these files, stats contained in those dentries can be stale. Consider the following scenario (All following operations happen in a single thread of the application):
* w1 is done on f1, write syscall completes with success. w1 is cached in write-behind.
* w2 is done on f2, write syscall completes with success. w2 is cached in write-behind.
* readdirp on parent directory is done. In response, f1 and f2 are fetched. stats for f1 and f2 are cached in kernel attribute cache.
* kernel/application does fstat on f1 and f2. Stats returned wouldn't account for w1 and w2.
What patch does is to not send stats for f1 and f2 in readdirp response, so that kernel is forced to do a lookup/getattr which will be serialized with w1 and w2 and fetch correct values.
Thanks,Vijay_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://lists.gluster.org/mailman/listinfo/gluster-devel
_______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://lists.gluster.org/mailman/listinfo/gluster-devel
