Checking for split-brain in GlusterFS identifies files whose replica copies have diverged, preventing inconsistent reads and guiding safe healing decisions.
On replicated volumes, GlusterFS stores the same file on multiple bricks and tracks replica state using the AFR translator. The gluster volume heal command can query that state and report entries flagged as split-brain per brick, usually as file paths that need a decision on which copy is authoritative.
Split-brain checks must run on a node in the trusted pool and apply to volumes that maintain replicas. Split-brain entries cannot be healed automatically until a resolution policy is applied, and selecting the wrong “winner” can overwrite valid data on other replicas.
Steps to check for split-brain in GlusterFS:
- List available volumes to confirm the target volume name.
$ sudo gluster volume list volume1
- List split-brain entries for the target volume.
$ sudo gluster volume heal volume1 info split-brain Brick node1:/srv/gluster/brick1 Number of entries in split-brain: 2 /dir/file1 - Is in split-brain /dir/file4 - Is in split-brain Brick node2:/srv/gluster/brick1 Number of entries in split-brain: 2 /dir/file1 - Is in split-brain /dir/file4 - Is in split-brain
No split-brain entries are indicated by Number of entries in split-brain: 0 on each brick.
- Record any reported paths or parent directories before attempting split-brain resolution.
Split-brain listings can show parent directories for GFID conflicts.
Split-brain resolution selects one copy as authoritative and can permanently discard the other replica contents.
Mohd Shakir Zakaria is a cloud architect with deep roots in software development and open-source advocacy. Certified in AWS, Red Hat, VMware, ITIL, and Linux, he specializes in designing and managing robust cloud and on-premises infrastructures.
