Bug 809193

Summary:	md-cache timeout 0 is ineffective
Product:	Red Hat Gluster Storage	Reporter:	Brian Foster <bfoster>
Component:	unclassified	Assignee:	Brian Foster <bfoster>
Status:	CLOSED CURRENTRELEASE	QA Contact:	SATHEESARAN <sasundar>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	2.0	CC:	bfoster, gluster-bugs, sdharane, vbellur
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	glusterfs-3.4.0qa2-1	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2015-08-10 07:47:12 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Brian Foster 2012-04-02 17:41:03 UTC

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.

Comment 1 Brian Foster 2012-04-02 17:51:27 UTC

http://review.gluster.com/3066

Comment 2 Anand Avati 2012-04-02 18:25:20 UTC

CHANGE: http://review.gluster.com/3066 (md-cache: fix time comparison to support 0 timeout) merged in master by Vijay Bellur (vijay)

Comment 4 SATHEESARAN 2013-07-23 19:53:44 UTC

Is there any test steps to verify this bug ?

Comment 5 Brian Foster 2013-07-24 10:23:41 UTC

(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).

Comment 6 SATHEESARAN 2013-08-05 10:28:07 UTC

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