Closed gluster-ant closed 3 years ago
Time: 20190628T01:31:57 homma at allworks.co.jp commented: I saw the source code, and found that in up_link_cbk(), upcall_cache_invalidate() is called with flags=UP_UPDATE_CLIENT for the parent directory. When upcall_cache_invalidate() is called with flags=UP_UPDATE_CLIENT (equals to UP_ATIME), cache-invalidation notification is not sent to the clients. It also applies to up_unlink_cbk(), up_rename_cbk(), and up_rmdir_cbk().
In all cases, upcall_cache_invalidate() is called with UP_PARENT_DENTRY_FLAGS for the inode that is created/deleted/renamed, but notification will never be sent to clients that have cache entry of only the parent directory.
Time: 20190716T03:23:52 homma at allworks.co.jp commented: I have confirmed that the problem persists on release 6.3.
On release 6, metadata cache of directories are refreshed by 'ls -l' for 1-way distributed volumes, because of dht pass-through. In that case, the problem is reproduced by the following steps: On client#1: stat dir1 dir2 On client#2: stat dir1 dir2 On client#1: echo test > dir1/test On client#1: ln dir1/test dir2/test On client#1: rm dir1/test On client#1: stat dir1 dir2 On client#2: stat dir1 dir2
On client#2, mtime and ctime of dir2 are not updated until expiration of metadata cache.
Thank you for your contributions. Noticed that this issue is not having any activity in last ~6 months! We are marking this issue as stale because it has not had recent activity. It will be closed in 2 weeks if no one responds with a comment here.
Closing this issue as there was no update since my last update on issue. If this is an issue which is still valid, feel free to open it.
URL: https://bugzilla.redhat.com/1724624 Creator: homma at allworks.co.jp Time: 20190627T12:30:10
Description of problem: With cache invalidation enabled, a file creation by LINK does not invalidate cache of the parent directory.
Version-Release number of selected component (if applicable): glusterfs-fuse.x86_64 5.6-1.el7 from centos-gluster5 repository
How reproducible: Often (depending on the timing of cache expiration)
Steps to Reproduce:
Actual results: Timestamp of dir2 on client#2 is not updated. About ten minutes later, cache on client#2 expires and timestamp of dir2 is updated.
Expected results: Timestamp of dir2 is updated immediately.
Additional info: Dovecot detects changes of the mailbox by mtime of Maildir/new directory, this results in up to 10 minutes delay in arrival of new mails.