+++ This bug was initially created as a clone of Bug #1622549 +++ Description of problem: If requested start time and end time doesn't fall into first HTIME file, then history API fails even though continuous changelogs are avaiable for the requested range in other HTIME files. This is induced by changelog disable and enable which creates fresh HTIME index file. Version-Release number of selected component (if applicable): mainline How reproducible: Always Steps to Reproduce: 1. Setup gluster volume and let the I/O happen 2. Enable changelog 3. sleep for some time 4. Disable changelog 5. sleep for sometime 6. Enable changelog 7. Use the sample c program attached to query history API with start time after step 6 Actual results: History fails Expected results: History API should not fail if continuous changelogs are available even if it's second HTIME file. Additional info: --- Additional comment from Kotresh HR on 2018-08-27 08:56 EDT --- Steps to run the program. 1. Place both header file and C program attached in a directory 2. Compile gcc -o get-history get-history.c -lgfchangelog 3. Run get-history <start-time> <end-time> --- Additional comment from Worker Ant on 2018-08-27 09:18:10 EDT --- REVIEW: https://review.gluster.org/21016 (libgfchangelog: Fix history changelog) posted (#1) for review on master by Kotresh HR --- Additional comment from Worker Ant on 2018-08-31 09:29:16 EDT --- COMMIT: https://review.gluster.org/21016 committed in master by "Amar Tumballi" <amarts> with a commit message- libgfchangelog: Fix changelog history API Problem: If requested start time and end time doesn't fall into first HTIME file, then history API fails even though continuous changelogs are avaiable for the requested range in other HTIME files. This is induced by changelog disable and enable which creates fresh HTIME index file. Cause and Analysis: Each HTIME index file represents the availability of continuous changelogs. If changelog is disabled and enabled, a new HTIME index file is created represents non availability of continuous changelogs. So as long as the requested start and end falls into single HTIME index file and not across, history API should succeed. But History API checks for the changelogs only in first HTIME index file and errors out if not available. Fix: Check in all HTIME index files for availability of continuous changelogs for requested change. fixes: bz#1622549 Change-Id: I80eeceb5afbd1b89f86a9dc4c320e161907d3559 Signed-off-by: Kotresh HR <khiremat>
REVIEW: https://review.gluster.org/21197 (libgfchangelog: Fix changelog history API) posted (#1) for review on release-4.1 by Kotresh HR
COMMIT: https://review.gluster.org/21197 committed in release-4.1 by "Shyamsundar Ranganathan" <srangana> with a commit message- libgfchangelog: Fix changelog history API Problem: If requested start time and end time doesn't fall into first HTIME file, then history API fails even though continuous changelogs are avaiable for the requested range in other HTIME files. This is induced by changelog disable and enable which creates fresh HTIME index file. Cause and Analysis: Each HTIME index file represents the availability of continuous changelogs. If changelog is disabled and enabled, a new HTIME index file is created represents non availability of continuous changelogs. So as long as the requested start and end falls into single HTIME index file and not across, history API should succeed. But History API checks for the changelogs only in first HTIME index file and errors out if not available. Fix: Check in all HTIME index files for availability of continuous changelogs for requested change. Backport of: > Patch: https://review.gluster.org/21016/ > BUG: bz#1622549 > Change-Id: I80eeceb5afbd1b89f86a9dc4c320e161907d3559 > Signed-off-by: Kotresh HR <khiremat> (cherry picked from commit 35aa67001c8fac99b040fbc61f36ef4f1b1590ac) fixes: bz#1630141 Change-Id: I80eeceb5afbd1b89f86a9dc4c320e161907d3559 Signed-off-by: Kotresh HR <khiremat>
This bug is getting closed because a release has been made available that should address the reported issue. In case the problem is still not fixed with glusterfs-4.1.5, please open a new bug report. glusterfs-4.1.5 has been announced on the Gluster mailinglists [1], packages for several distributions should become available in the near future. Keep an eye on the Gluster Users mailinglist [2] and the update infrastructure for your distribution. [1] https://lists.gluster.org/pipermail/announce/2018-September/000113.html [2] https://www.gluster.org/pipermail/gluster-users/