[Bugs] [Bug 1199906] New: Changelog: Include leftover changelog into existing htime file

[bugzilla at redhat.com]

https://bugzilla.redhat.com/show_bug.cgi?id=1199906

            Bug ID: 1199906
           Summary: Changelog: Include leftover changelog into existing
                    htime file
           Product: GlusterFS
           Version: mainline
         Component: geo-replication
          Assignee: bugs at gluster.org
          Reporter: sarumuga at redhat.com
                CC: bugs at gluster.org, gluster-bugs at redhat.com



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:

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.