Tobias Wilken: > Some tests I did: > One test to compare the performance, was to run a `while(true); do ls -al; > done;` on /data/share/core/files/ and on /data/applications/core/ > current on NodeA, while creating files on NodeB. > Without aufs I can't say if the time offset relies on the console output or > on the glusterfs - in other words: The files were directly available. > On the aufs mount it took several seconds. > > The other test of inotify: > Setting up an inotifywait on NodeA for /data/share/core/files/ (the > glusterfs mount) and changing files on NodeB. Inotify didn't recognized the > change. > I also set it up on the same node, on the mounted folder, and it recognized > the change.
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? If so, I'd suggest you to contact the author of gluseterfs because it simply breaks inotifywatch, inotifywait or any other inotify-based tools. > So AFAIK inotify don't work for this (right now). How does the udba=reval > recognize changes on the filesystem? 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. J. R. Okajima ------------------------------------------------------------------------------ Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev
