Let me make sure,
- NodeA, set inotify to glusterfs
- NodeB, change a file in gluseterfs
- NodeA, you can see the change immediately
- NodeA, you cannot receive the inotify event
Right?
Yes
If so, I'd suggest you to contact the author of gluseterfs because it
simply breaks inotifywatch, inotifywait or any other inotify-based tools.
Yeah, I also wrote to their mailing list. Today I learned many things about
filesystems :-)
Current it seems to be a fuse problem, I found the same problem for sshfs,
which is fuse based, too
It is a subset of udba=inotify in dentry revalidation, and checks
- the sign of the value of inode's link count (plus or zero)
- the file-type
- the pair of name and inode
If any of these are changed, aufs discards cache and re-lookup.
Is there any timeout, where aufs checks the underlying folder, if none of
the events occurs, too?
After some time I can access the changed file over aufs, too. And I don't
know, why this happen, if it only refreshes the cache based on this events.
I try to get a bit more into glusterfs if such events occur and a later
time, but I don't know why that should be.
To fix the problem, you're right, I have to search on the fuse/glusterfs
side. But maybe we can find a workaround for me, until I or someone more
experienced can fix it.
My thoughts are currently in the direction, to reduce/disable the aufs
cache, or if there is a timeout for the cache refresh to lower it ... - I
have no idea about the consequences in case of performance or developing
work of such "changes".
Best regards
Tobias Wilken
------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
