Bug 1370832

Summary: Directory timestamps change after add-brick
Product: [Community] GlusterFS Reporter: Hans Henrik Happe <happe>
Component: distributeAssignee: bugs <bugs>
Status: CLOSED EOL QA Contact:
Severity: high Docs Contact:
Priority: unspecified    
Version: 3.7.13CC: amukherj, bugs, nbalacha, rgowdapp, spalai
Target Milestone: ---Keywords: Triaged
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-03-08 10:54:34 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Hans Henrik Happe 2016-08-27 13:26:47 UTC 
Description of problem:
After add-brick directory timestamps change to current time.

Version-Release number of selected component (if applicable):

OS: CentOS 6.8
Gluster: 3.7.13 using centos-release-gluster37
Underlying filesystems tested: ZFS 0.6.5.7, EXT4


How reproducible:
Every time.

Steps to Reproduce:
One server is enough. Have tested with one initial brick and two initial bricks.

server: gluster vol create test <brick1>
server: gluster vol start test
client: (mount in /mnt/test)
client: mkdir /mnt/test/foo
client: (check foo timestamps)
server: gluster vol add-brick test <brick2>
client: (if NFS re-mount is required, guess caching)
client: (foo timestamps now changed)
server: gluster vol remove-brick test <brick2> start
server: gluster vol remove-brick test <brick2> commit
client: (foo mtime now back to expected time)

Actual results:
Directory have different timestamps.
When brick is removed again, the timestamps are correct again.

Expected results:
Directory timestamps are not altered.

Additional info:
Comment 1 Kaushal 2017-03-08 10:54:34 UTC 
This bug is getting closed because GlusteFS-3.7 has reached its end-of-life.

Note: This bug is being closed using a script. No verification has been performed to check if it still exists on newer releases of GlusterFS.
If this bug still exists in newer GlusterFS releases, please reopen this bug against the newer release.