Downstream patch: https://code.engineering.redhat.com/gerrit/#/c/101659/

Leaving a need-info on Nag for his decision on QE ack for this bug which fixes an issue found while debugging gss bz 1414456

Update:
========

Build used: glusterfs-3.12.2-8.el7rhgs.x86_64


Scenario :

1) create 2 * 3 volume and start 
2) kill one of the brick ( N1:b0 )
3) create dirs, file, soft link, hard link and char files.
4) wait for few minutes and modify/append some files and create files inside some dirs 
4) wait for few min
5) go to node where brick is up ( in the same replica set )
6) "ls -lrt" on the data and note down the timings
7) bringup the brick
9) After healing , from the node where brick was brough down previously ( step 2 ) do "ls -lrt" on the data 
10) compare the atime/mtime from step 6 and step 9

Observation :

All the files, soft links, hardlinks and char files restored the time but only below dir is not restored the time.


From N1:

drwxr-xr-x. 2 root root    47 Apr 24 09:01 dir1
drwxr-xr-x. 2 root root    47 Apr 24 09:01 dir2


From N2:

drwxr-xr-x. 2 root root    47 Apr 24 08:36 dir1
drwxr-xr-x. 2 root root    47 Apr 24 08:36 dir2

> attribute for N2

# getfattr -d -m . -e hex  /bricks/brick0/testvol_distributed-replicated_brick1/dir1
getfattr: Removing leading '/' from absolute path names
# file: bricks/brick0/testvol_distributed-replicated_brick1/dir1
security.selinux=0x73797374656d5f753a6f626a6563745f723a676c7573746572645f627269636b5f743a733000
trusted.afr.23-client-0=0x000000000000000000000000
trusted.afr.dirty=0x000000000000000000000000
trusted.gfid=0x342afbb2ce814094895409deed35465d
trusted.glusterfs.dht=0x00000000000000007fffffffffffffff
trusted.glusterfs.dht.mds=0x00000000

# 

> scenario for that dir is , kill b0 and create dir from client and touch a empty file inside dir and after 5 min brought up b0.

Placing Needinfo to check the above behavior

Vijay,

What is happening is when the empty file is  created on the down brick (after bringing it up) as a part of entry self-heal, it changes time stamp of the parent directory.

The patch for this bug basically handles fixing timestamps during metadata self-heal. We need to do it for entry self-heals too. But given it is a day one issue, you could probably raise a separate bug for it that can be targeted for the next release.

A simple reproducer would be:
-create 1x2 volume
-create a 'dir' from mount
-kill one brick
-touch 'dir/file'
-bring back brick after some time
-after healing, mtime and ctime of 'dir' will be different, while it should be same.

(In reply to Ravishankar N from comment #9)
> Vijay,
> 
> What is happening is when the empty file is  created on the down brick
> (after bringing it up) as a part of entry self-heal, it changes time stamp
> of the parent directory.
> 
> The patch for this bug basically handles fixing timestamps during metadata
> self-heal. We need to do it for entry self-heals too. But given it is a day
> one issue, you could probably raise a separate bug for it that can be
> targeted for the next release.
> 
> A simple reproducer would be:
> -create 1x2 volume
> -create a 'dir' from mount
> -kill one brick
> -touch 'dir/file'
> -bring back brick after some time
> -after healing, mtime and ctime of 'dir' will be different, while it should
> be same.

Thanks Ravi for the explanation. I will raise separate bug for the same.

Moving status to verified.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2018:2607