Description of problem: ======================= The purpose of checkpoint in status was to track whether the files to the time is synced or not. With the addition of last_synced in the status the usecase of checkpoint is very minimal and can be removed. The status detail command is too large to fit in the screen for user to track, we can avoid displaying things which do not make sense any more. Checkpoint Completed yes/no is another such thing. It sets the value yes/no based out of "If last_synced > checkpoint time" set yes else set no. This is how current status details output is: [root@georep1 scripts]# gluster volume geo-replication master 10.70.46.154::slave status detail MASTER NODE MASTER VOL MASTER BRICK SLAVE USER SLAVE SLAVE NODE STATUS CRAWL STATUS LAST_SYNCED ENTRY DATA META FAILURES CHECKPOINT TIME CHECKPOINT COMPLETED CHECKPOINT COMPLETION TIME --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- georep1 master /rhs/brick1/b1 root 10.70.46.154::slave 10.70.46.101 Passive N/A N/A N/A N/A N/A N/A N/A N/A N/A georep1 master /rhs/brick2/b2 root 10.70.46.154::slave 10.70.46.101 Passive N/A N/A N/A N/A N/A N/A N/A N/A 2015-05-21 14:00:57 georep3 master /rhs/brick1/b1 root 10.70.46.154::slave 10.70.46.154 Active Changelog Crawl 2015-05-21 14:03:50 0 377 0 0 2015-05-21 13:59:24 Yes 2015-05-21 14:14:10 georep3 master /rhs/brick2/b2 root 10.70.46.154::slave 10.70.46.154 Active Changelog Crawl 2015-05-21 14:02:02 0 372 0 0 2015-05-21 13:59:24 Yes 2015-05-21 14:04:37 georep2 master /rhs/brick1/b1 root 10.70.46.154::slave 10.70.46.103 Passive N/A N/A N/A N/A N/A N/A N/A N/A N/A georep2 master /rhs/brick2/b2 root 10.70.46.154::slave 10.70.46.103 Passive N/A N/A N/A N/A N/A N/A N/A N/A N/A [root@georep1 scripts]# Version-Release number of selected component (if applicable): glusterfs-3.7.0-2.el6rhs.x86_64
Since Checkpoints are used in many cases like during Cluster Failover/Failback and Replace brick scenarios. We will plan to move checkpoint as separate command and with multiple checkpoint support. BZ for multiple Checkpoints 889171
As mentioned in comment 2 the checkpoints remains valid in different scenarios. Hyper-convergence use case is based on checkpoints. Closing this request of enhancements.