Sooner or later, every self-hosted setup runs into the same wall: you need more storage, but you don't need a distributed storage cluster. Maybe you have a media server whose library keeps growing, or a backup target that's slowly filling up, or a homelab with three or four machines that each have some spare disk sitting idle. The obvious answers, Ceph, GlusterFS, or a full-blown SAN, are overkill for this kind of problem. They bring their own operational burden: multiple daemons, quorum requirements, network overhead, and a learning curve that doesn't pay for itself unless you're running dozens of terabytes across a real cluster with redundancy requirements.
This is the gap that MergerFS fills. It's a union filesystem, meaning it takes several separate storage locations and presents them to applications as a single, unified mount point. It doesn't stripe data, it doesn't replicate it, and it doesn't do anything clever with erasure coding. It just merges directory trees. Combined with NFS to bring in storage from a second machine, you can build a pool that behaves like one big disk without touching a single line of cluster configuration.
This article walks through building exactly that: an NFS server exporting a chunk of storage, a client machine mounting it locally, and MergerFS combining that NFS mount with local disk into a single pooled filesystem. Along the way we'll cover the NFS version choice, placement policies, permissions, failure behavior, and backup strategy, because a union filesystem is not, and never will be, a backup.
