Description of problem:

In some scenario some unindexed files (files with no valid xtime) won't be copied by geo-rep from master to slave

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

master
release-3.2

How reproducible:

Reliably

Steps to Reproduce:

1. rm -rf /backing/dir /slave/dir && mkdir /slave/dir
2. gluster volume create my-vol my-ip:/backing-dir && gluster volume start my-vol
3. mount -t glusterfs localhost:my-vol /mnt/gluster
4. mkdir -p /mnt/gluster/a/{b,c}
5. touch /mnt/gluster/a/b/d
6. gluster volume set my-vol indexing on
7. touch /mnt/gluster0/a/c/e
8. gluster volume geo-replication pop /slave/dir start
9. sleep 30 && find /slave/dir -type f

Actual results:

/slave/dir/a/c/e

Expected results:

/slave/dir/a/b/d
/slave/dir/a/c/e

Additional info:

The bug was spotted in code and the above is a PoC demo.

The fallback xtime that is sent over the wire is always -∞ for master side unindexed files (although their on-disk xtime is being properly set to current xtime), cf.

https://github.com/gluster/glusterfs/blob/c66ced7d87/xlators/features/marker/utils/syncdaemon/master.py#L84

Thus if we set up a scenario so that there is no reason for gsyncd to look at the (originally) unindexed file again, it will be omitted from synchronization. (This is a bit tricky because in the most simplistic scenarios the file will be revisited due to its freshly set xtime).