Hide Forgot
Description of problem: While debugging another translator I noticed that md-cache caching still occurs even when the timeout option is set to 0. Version-Release number of selected component (if applicable): How reproducible: 100% Steps to Reproduce: I don't have a specific test case for this beyond a debugging session. Amar apparently knows of several filed bugs that are due to this issue and will mark those as duplicates here.
http://review.gluster.com/3066
CHANGE: http://review.gluster.com/3066 (md-cache: fix time comparison to support 0 timeout) merged in master by Vijay Bellur (vijay)
Is there any test steps to verify this bug ?
(In reply to SATHEESARAN from comment #4) > Is there any test steps to verify this bug ? I don't know of a specific regression test that can be used for this bug. It's a narrow timing condition if I recall. The best bet might be set md-cache-timeout to 0 and verify that caching doesn't occur (i.e., change metadata on the brick or via a separate client and verify the initial client always picks up the change immediately).
Verified with glusterfs-3.4.0.15rhs-1.el6rhs I performed the following steps RHS Side ========= 1. Created a distributed type of gluster volume with 2 bricks (i.e) gluster volume create <vol-name> <brick1> <brick2> Client - RHEL 6.4 ================== 2. Mounted the volume on 2 RHEL6.4 clients (i.e) mount.glusterfs <RHS-Server>:<vol-name> 3. Created few files on the mount point (i.e) touch <mount-point>/file{1,2,3,4,5,6,7,8,9} Test - 1 ======== 1. Set the md-cache-timeout to 0 (i.e) gluster volume set <vol-name> performance.md-cache-timeout 0 2. Check for stat on file1 on mount point (i.e) stat <mount-point>:/file1 3. changed the access time of a file1 (i.e) touch -a <mount-point>:/file1 4. Immediately look for stat of the same file on another client (i.e) stat <mount-point>:/file1 5. Look for the change in atime, and mtime Observation =========== atime and ctime of the file changed immediately Test - 2 ======== 1. Set the md-cache-timeout to 60 (i.e) gluster volume set <vol-name> performance.md-cache-timeout 60 2. Check for stat on file2 on mount point (i.e) stat <mount-point>:/file1 3. changed the access time of a file1 (i.e) touch -a <mount-point>:/file1 4. Immediately look for stat of the same file on another client (i.e) stat <mount-point>:/file1 5. Look for the change in atime, and mtime Observation =========== atime and ctime on Client 2 haven't changed for sometime ( around 58 -62 seconds ) Based on behaviour observed from Test-1 and Test-2, moving this bug as VERIFIED