path: root/tests/changelog.rc
Commit message (Collapse)AuthorAgeFilesLines
* changelog: test case for verifying empty changelogs avoidedSaravanakumar Arumugam2015-07-271-0/+5
| | | | | | | | | | | | | Test case added to check NO EMPTY changelogs gets created over changelog rollover period. Change-Id: I83323644e1a0c4b920a472e1179606a0fd54d1d9 BUG: 1237000 Signed-off-by: Saravanakumar Arumugam <> Reviewed-on: Tested-by: Gluster Build System <> Reviewed-by: Venky Shankar <> Tested-by: NetBSD Build System <>
* features/changelog: Consider only changelog on/off as changelog breakageKotresh HR2015-05-021-0/+4
Earlier, both chagelog on/off and brick restart were considered to be changelog breakage and treated as changelog not being continuous. As a result, new HTIME.TSTAMP file was created on both the above cases. Now the change is made such that only on changelog enable/disable, the changelog is considered to be discontinuous. New HTIME.TSTAMP file is not created on brick restart, the changelogs files are appended to last HTIME.TSTAMP file. Treating changelog as continuous in above scenario is important as changelog history API will fail otherwise. It can successfully get changes between start and end timestamps only when changelog is continuous (Changelogs in single HTIME.TSTAMP file are treated as continuous). Without this change, changelog history API would fail, and it would become necessary to fallback to other mechanisms like xsync FSCrawl in case geo-rep to detect changes in this time window. But Xsync FSCrawl would not be applicable to other consumers like glusterfind. Rationale: 1. In plain distributed volume, if brick goes down, no I/O can happen onto the brick. Hence changelog is intact with data on disk. 2. In distributed replicate volume, if brick goes down, since self-heal traffic is captured in changelog. Eventually, I/O happened whend brick down is captured in changelog. Change-Id: I2eb66efe6ee9a9228fb1fcb38d6e7696b9559d5b BUG: 1211327 Signed-off-by: Kotresh HR <> Reviewed-on: Reviewed-by: Venky Shankar <> Tested-by: Venky Shankar <> Tested-by: Gluster Build System <> Tested-by: NetBSD Build System