GlusterFS: distributed storage from ordinary servers, and what to check before you deploy

What GlusterFS solves, and for whom

The README describes Gluster as "a software defined distributed storage that can scale to several petabytes" that "provides interfaces for object, block and file storage". Read that alongside the repository layout and the practical shape is narrower than the slogan: the project is a scale-out network filesystem in which each participating server contributes local disk, and clients mount the aggregate over FUSE as if it were a single directory tree.

The audience is infrastructure teams that already have Linux machines with spare disks and want shared storage without buying an appliance or a SAN. The repository carries directories for replication, healing, geo-replication, snapshots and erasure coding, so the intended deployments are the ones where a single server's disks are not enough and where losing one machine should not lose data. The topics list names k8s-sig-storage and libgfapi, which tells you the project is also consumed as a storage backend by other software rather than only mounted by hand.

It is not for a single-server home setup. The moment you run one node you have added a distributed system without gaining redundancy, and the healing machinery has nothing to heal.

How a GlusterFS volume is put together

The architecture visible in the tree is layered. The cli/ directory holds the gluster command line, xlators/ holds the translator modules that implement behaviour, glusterfsd/ holds the server daemon, and api/ exposes libgfapi so applications can talk to a volume without a kernel mount. A volume is the unit you create, and it is backed by bricks, which are export directories on the participating servers.

Different volume types change the data flow. A replicated volume writes each file to every brick in the set, so reads can come from any copy and a node failure leaves the data reachable. A distributed volume spreads files across bricks, which grows capacity but leaves each file on exactly one brick. A dispersed volume uses erasure coding, storing fragments plus parity so capacity overhead is lower than full replication at the cost of reconstruction work on read and heal. The xlators/ tree and the heal/ directory are where that repair logic lives.

The operational consequence is that volume type is not a detail you tune later. It determines how much usable capacity you get, what happens during a node outage, and how much network traffic a heal generates. The README does not document these trade-offs; it points to docs.gluster.org, which is where the choice has to be made.

Installing GlusterFS and creating a first replicated volume

The README does not inline installation steps. It says quick instructions to build and install are in the INSTALL file, and links a Quick Start Guide on docs.gluster.org. The repository ships autogen.sh, configure.ac and Makefile.am, so building from source is the path the project documents for people whose distribution package is too old.

What the README does document is testing. It states that the source contains functional tests under tests/, that they are run against every patch submitted for review, and that a single test can be invoked directly.

bash# /bin/bash ${path_to_gluster}/tests/basic/rpc-coverage.t

The same guide gives a prove variant for machines that have prove installed, which is the form to use when you want the test harness output rather than a bare exit code.

bash# prove -vmfe '/bin/bash' ${path_to_gluster}/tests/basic/rpc-coverage.t

Before running either, note the warning the README gives in plain terms: do not run the test suite on a machine where production GlusterFS is running, because it would blindly kill all gluster processes in each run. The repository's run-tests.sh is the full-suite entry point named in the README, and the same warning applies to it.

The README does not list package names, service names or mount commands, so there is no verified install command to reproduce here. For a first real deployment, follow the INSTALL file and the Quick Start Guide: they are the two sources the project itself points at, and anything beyond them would be guesswork.

Where GlusterFS is the wrong tool

The most common mismatch is expecting block or object semantics from a filesystem. The README's claim of object and block interfaces describes interfaces the project provides, not a drop-in replacement for a block device or an S3 endpoint. If your application needs raw block storage, or needs HTTP object access with its own consistency model, a filesystem mount over FUSE is the wrong layer.

FUSE itself is a constraint. Every client read and write passes through a userspace filesystem process, which adds latency and CPU cost compared with a local disk or a kernel NFS client. For small-file, metadata-heavy workloads this is where deployments get unhappy, and the repository gives no performance figures to argue otherwise.

Split brain is the failure mode to plan for. When a replicated set loses contact between its members, both sides can keep accepting writes, and reconciling them afterwards is manual work. The heal/ directory exists because this is a real operational task, not a rare edge case. A team without someone who understands quorum and heal status should not run replicated volumes over an unreliable network.

Finally, the client story is Linux. The repository is a Linux filesystem project with a FUSE client and libgfapi; the README offers no Windows client, so a mixed-OS environment needs another protocol in front.

GlusterFS compared with Ceph and with NFS

Ceph and GlusterFS are the two names that come up together, and the difference is architectural. Ceph puts a metadata service and a placement algorithm in front of its object store, and exposes block, object and file storage from that single foundation. GlusterFS has no central metadata server: clients compute file locations from the volume layout and talk to bricks directly, which removes a metadata bottleneck and also removes a place to keep global state. If you need block volumes for virtual machines, Ceph's block interface is the more direct fit. If you need a POSIX filesystem across a handful of servers with no metadata tier to run, GlusterFS is the simpler shape.

NFS is the other comparison, and it is a different question. NFS exports one server's filesystem; GlusterFS aggregates several servers' disks. A single NFS server with a good disk array will beat a small GlusterFS cluster on latency and on operational simplicity. GlusterFS earns its place when one server's capacity or bandwidth is the ceiling, or when you need the export to survive a machine loss without a failover appliance.

Maintenance status, licensing and upgrade cost

The repository is not archived, and the last push was on 2026-09-22. The most recent release listed is v11.2 from 2025-07-02. That is the factual position on activity; the README itself carries no end-of-life or support statement, so claims about the project being dead or alive should be checked against the release notes and mailing list rather than inferred.

The licence is stated plainly in the README: Gluster is dual licensed under GPLV2 and LGPLV3+, with COPYING-GPLV2 and COPYING-LGPLV3 in the repository root. The practical reading is that the server side is GPLv2 and the client library carries the LGPL option, which matters if you link libgfapi into a proprietary application. That is a description of what the files say, not legal advice; a lawyer should confirm how it applies to your distribution model.

Upgrade cost is the part the README does not document. There is no rollback procedure in the README, and no statement about on-disk format compatibility between release lines. A volume created on one version and opened by another is the risk to verify before scheduling maintenance, and the release notes on docs.gluster.org are the place that answer would live.

Editorial conclusion

GlusterFS suits teams that already run Linux servers and need a POSIX filesystem shared across several nodes, with replication or erasure coding chosen per volume. It is the wrong tool when the workload needs block devices or S3-style object access, when the client is Windows, or when nobody can own the operational work of bricks, quorums and heal. Before adopting it, verify three things against the version you intend to run: which release line is still receiving fixes, whether your distribution ships a current glusterfs-server package or you must build from source, and that your kernel exposes FUSE. Start with a replicated volume across three nodes and a real write and read test, not with a production dataset.

Frequently asked questions

Official sources

1. gluster/glusterfs on GitHub
2. License: GPL-2.0
3. Project website
4. README
5. Releases