Bug 1412545

Description of problem:
=====================
when a heal happens, especially a entry or gfid heal, the ctime changes with the heal. This is applied even on the source file which is not right.
The ctime can be consumed by many applications.
Simple example is our QE automation cases, which calculate are-equal checksums before and after heal to check the heal functionality. This will fail almost everytime because the ctime changes with the healing

Suppose there is a file f1 which was created on a 1x2 volume with one brick down(say b1), which has a ctime of say 9:00AM
if the b1 is brought up after some time say 9:10Am, and the heal completes, the file f1 has a new ctime as 9:10AM

this is wrong, given that the new ctime is now changed even on the source file(b2 brick) and reflects the latest ctime on mount (9:10AM)

Applications will fail if they are noting the ctime of original file for heal validation or any other archival application systems can fail

as one of the dev member discussed with me, we may have to store ctime in the xattrs of src file to avoid this problem , or look at other ways to handle this

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

How reproducible:
-------------------
always


Steps to Reproduce:
=====================
explained for gfid healing(same can be done of entry healing too)

1)created a 1x2 volume say b1 and b2 are the bricks on n1 and n2
2)fuse mounted volume, created a file file1===> say its gfid is 100
3) killed b1,
4) delete file1 from mount, and recreated a new file with same name, ie file1--->let's say this got a gfid as "200"
5) now brought b1 online, healing succeeded.
But with healing what is happening is the file1 has a new ctime as below

on mount before heal
[root@dhcp47-147 dir1]# stat f1
  File: ‘f1’
  Size: 3               Blocks: 1          IO Block: 131072 regular file
Device: 28h/40d Inode: 9504604878251802295  Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Context: system_u:object_r:fusefs_t:s0
Access: 2017-01-12 13:04:09.998872000 +0530
Modify: 2017-01-12 13:04:16.626978963 +0530
Change: 2017-01-12 13:04:16.627978970 +0530
 Birth: -

(the above was the ctime of the source brick file)

and after heal:
[root@dhcp47-147 dir1]# stat f1
  File: ‘f1’
  Size: 3               Blocks: 1          IO Block: 131072 regular file
Device: 28h/40d Inode: 9504604878251802295  Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Context: system_u:object_r:fusefs_t:s0
Access: 2017-01-12 13:04:09.998872000 +0530
Modify: 2017-01-12 13:04:16.626978963 +0530
Change: 2017-01-12 13:07:23.732260887 +0530
 Birth: -
Actual results:

(above is the new ctime on source brick file, destination brick file and hence mount location too)