How to resolve GlusterFS split-brain using latest mtime

A file split-brain in a replicated GlusterFS volume is a latest-mtime candidate only when the replica with the newest modification time is the version to keep. The resolver copies that newest file over the other conflicting replicas so GlusterFS can clear the split-brain entry and resume normal self-heal.

The server-side gluster volume heal resolver works per conflicted path or GFID. List the split-brain entries, map each volume-relative path to the brick-side files, compare their modification times, and run gluster volume heal <volume> split-brain latest-mtime <path> from a node in the trusted pool.

The operation overwrites non-selected replicas, so pause writes to the affected file and keep a backup or copy when the contents matter. Do not use latest-mtime when brick clocks are skewed, when the newest copy is not the intended data version, or when the conflict is a directory type mismatch that GlusterFS cannot heal with this policy.

Related: How to resolve GlusterFS split-brain using bigger-file
Related: How to monitor GlusterFS health

Steps to resolve GlusterFS split-brain using latest mtime:

  1. Review the replica bricks and self-heal daemons before choosing an mtime winner. 
    $ sudo gluster volume status volume1
Status of volume: volume1
Gluster process                             TCP Port  RDMA Port  Online  Pid
------------------------------------------------------------------------------
Brick node1:/srv/gluster/brick1             49152     0          Y       13241
Brick node2:/srv/gluster/brick2             49153     0          Y       13907
Self-heal Daemon on node1                   N/A       N/A        Y       14112
Self-heal Daemon on node2                   N/A       N/A        Y       14203

    Bring disconnected bricks back online before resolving split-brain; the selected copy cannot heal to an offline replica.

  2. Check that the brick clocks are synchronized before trusting modification time. 
    $ chronyc tracking
Reference ID    : C0000201 (ntp1.example.net)
System time     : 0.000018421 seconds fast of NTP time
Last offset     : +0.000011340 seconds
RMS offset      : 0.000039517 seconds
Leap status     : Normal

    Use a content-based resolver or manual copy workflow instead when the bricks have material clock skew.

  3. Identify the split-brain entries for the volume. 
    $ sudo gluster volume heal volume1 info split-brain
Brick node1:/srv/gluster/brick1
/dir/file1 - Is in split-brain
Number of entries in split-brain: 1

Brick node2:/srv/gluster/brick2
/dir/file1 - Is in split-brain
Number of entries in split-brain: 1

    The listed paths are relative to the volume root and should be reused verbatim in the resolve command. Use the gfid: string instead when the output provides only a GFID value.

    Related: How to check for split-brain in GlusterFS

  4. Pause application writes to the affected file.

    Writes during resolution can create another divergent copy or replace data that has not been reviewed.

  5. Compare the conflicting brick-side modification times. 
    $ sudo stat --format='%n %y' /srv/gluster/brick1/dir/file1 /srv/gluster/brick2/dir/file1
/srv/gluster/brick1/dir/file1 2026-06-16 08:41:07.210000000 +0000
/srv/gluster/brick2/dir/file1 2026-06-16 08:32:55.918000000 +0000

    The brick directory from the split-brain listing plus the volume-relative path forms the on-disk path, such as /srv/gluster/brick1/dir/file1.

  6. Resolve the split-brain entry using the latest-mtime policy. 
    $ sudo gluster volume heal volume1 split-brain latest-mtime /dir/file1
Healed /dir/file1.

    Run the command once for each path or gfid: value that should use the newest modification time.

    The older-mtime replica contents are permanently replaced by the newest-mtime copy.

  7. Re-read the split-brain queue after the mtime-based heal. 
    $ sudo gluster volume heal volume1 info split-brain
Brick node1:/srv/gluster/brick1
Number of entries in split-brain: 0

Brick node2:/srv/gluster/brick2
Number of entries in split-brain: 0
  8. Check for a clean self-heal summary after the timestamp winner is copied. 
    $ sudo gluster volume heal volume1 info summary
Brick node1:/srv/gluster/brick1
Status: Connected
Total Number of entries: 0
Number of entries in heal pending: 0
Number of entries in split-brain: 0
Number of entries possibly healing: 0

Brick node2:/srv/gluster/brick2
Status: Connected
Total Number of entries: 0
Number of entries in heal pending: 0
Number of entries in split-brain: 0
Number of entries possibly healing: 0