Description of problem:

Geo-replication make use of changelog translator (which is used to 
capture all I/O operations happening in a Volume and this happens per 
brick).

All the I/O operations happening are stored in 
.glusterfs/changelogs/CHANGELOG.TS (where TS is timestamp).

All successful changelogs(in a session) are getting logged into HTIME file.

Now, we have a case where the Brick can go down (for example some crash) 
and Changelog logging stops.

Consider, gluster volume is started again.
Now, the last CHANGELOG (which captured I/Os just before crash) is 
getting included into the new HTIME file.

This leads to inconsistent timings. The last CHANGELOG should have been 
included into the previous HTIME file.

Solution is to modify changelog translator so that the last 
CHANGELOG will be included into the previous HTIME file.  It will be renamed as CHANGELOG.<Previous Changelog TS + 1>.

This will give better results when changes happened across a specific 
duration is asked for.



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


How reproducible:


Steps to Reproduce:
1. kill the glusterfsd brick daemon while changelogs are getting generated
2. There should be a CHANGELOG file without any extension.
3. Restart the brick daemon. Now the CHANGELOG file be included 
into new HTIME file.

Actual results:
CHANGELOG file is getting included into new htime file. 


Expected results:
Existing Changelog file, if any should get included into the previous htime file. Also, the file I/Os captured(in the changelog) should be propagated to slave by geo-rep session.

Additional info: