iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Longhorn and NFS are not always alternatives: Longhorn’s generic ReadWriteMany (RWX) volumes use NFSv4.1 behind the scenes. The meaningful choice is usually between Longhorn-managed RWX and a separately provisioned NFS share—or, for a different access pattern, Longhorn block volumes. Which fits depends on how applications access files, what storage infrastructure already exists, and what failure and recovery behavior you need.
What “Longhorn versus NFS” actually compares
Longhorn volumes are attached to a Linux node as block devices. Longhorn also uses NFS in two ways: as the filesystem-sharing mechanism for generic RWX volumes and as a supported backupstore protocol. So NFS is not simply the opposite of Longhorn; it may be part of a Longhorn design. Longhorn’s v1.13.0 terminology documentation describes these roles.
For shared files across Kubernetes nodes, the comparison is between a Longhorn-managed RWX volume and a separately provisioned NFS share. For storage attached to a workload as a block device, that is a different comparison: a shared NFS filesystem is not a direct substitute for a block volume.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →How Longhorn’s generic RWX volumes work
In Longhorn v1.13.0, a generic, non-migratable RWX volume is served by an NFSv4.1 server running in a share-manager-<volume-name> pod. A Service exposes that server for clients. Each client node needs an NFSv4 client, and Longhorn’s documented recovery behavior depends on node hostnames being unique. See the RWX Volume documentation.
#1 Best Overall
Longhorn characterizes this mode as “Suitable for general shared storage and multi-node file access workloads,” but also says it is “Not intended for general shared filesystem workloads.” Those qualifications apply to generic non-migratable RWX volumes; they do not establish that every application that can mount a shared filesystem is a good fit. Check the application’s access pattern and requirements rather than treating RWX as a universal shared-filesystem solution.
What a separate NFS share requires
Kubernetes does not create an NFS server as part of its built-in storage functionality. Its documentation states, “Kubernetes doesn’t include an internal NFS provisioner.” To make an NFS share available through a StorageClass, you need an external provisioner. The Kubernetes example supplies the NFS server, exported path, and read-only setting as configuration. The documentation gives NFS Ganesha with an external provisioner and the NFS subdir external provisioner as examples. See Kubernetes Storage Classes.
That arrangement separates responsibilities: the NFS server and its export provide the share, while the provisioner integrates it with Kubernetes storage provisioning. If shared storage is already available and the workload’s requirements match it, Longhorn’s RWX layer may add another component without solving a need you have. If no suitable share exists, Longhorn can provide an RWX path managed within its own architecture, with the client and server requirements described above.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Scan for outdated or missing drivers - takes under a minute3Repair Windows errors before they cause bigger problemsCompare the access pattern, failure domain, and recovery path
- Access model: Decide whether the workload needs a block device attached to a node or files shared across multiple nodes. Also check its file-locking and concurrent-access behavior; the documentation does not establish application compatibility for a particular workload.
- Existing infrastructure: A separately provisioned NFS share relies on an NFS server and external provisioner. Longhorn generic RWX uses a share-manager pod and Service, plus NFSv4 clients on client nodes.
- Failure domains: Identify which components and network paths must remain available for workloads to access data. Longhorn RWX fast failover concerns its NFS server pod; it does not describe recovery of an external NFS server.
- Recovery expectations: Establish what interruption an application can tolerate and how its data is backed up and restored. The cited feature documentation does not provide a performance ranking or cost comparison for a particular cluster.
Longhorn RWX behavior to account for
Migration is not live
Generic Longhorn RWX volumes are not capable of live migration. During migration, access remains with the source workload until migration completes and the destination takes over. That matters when planning workload moves; do not assume that a running workload can shift between nodes with uninterrupted shared-volume access. Longhorn’s RWX documentation describes this behavior.
Rank #3
Mount options and interrupted access
For Longhorn v1.13.0, the documented default NFS mount options are softerr, timeo=600, and retrans=5. If the NFS server remains inaccessible, requests can fail with ETIMEDOUT or EIO, and data loss may occur. These are version-specific documented details, not defaults to assume for every Longhorn release or NFS setup.
Longhorn allows custom options through the StorageClass nfsOptions parameter, but says it does not validate the supplied string. An invalid value can prevent a mount or volume creation. Check the documentation for the version actually deployed before changing mount options, and account for the consequences of a network partition or prolonged server outage.
Fast failover is a mechanism, not an uptime guarantee
Longhorn documents lease-based monitoring of the RWX NFS server pod. If the serving pod is unresponsive, the mechanism can create a replacement NFS server pod on another node. This describes recovery for Longhorn’s share-manager architecture; it is not a promise of zero interruption, and it does not describe failover for a separately provisioned NFS server. See Longhorn’s RWX Volume Fast Failover documentation.
When each option is a reasonable fit
Consider Longhorn RWX when
- You need shared-file access from multiple nodes and want Longhorn to provide its documented RWX architecture.
- Your client nodes can use NFSv4, and your workload can accommodate the documented migration and failure behavior.
- You have reviewed the Longhorn version’s RWX guidance and designed backup and recovery around your own failure requirements.
Consider a separate NFS share when
- You have an NFS server and export that meet the workload’s needs, and can operate or rely on an external provisioner for Kubernetes integration.
- You prefer the NFS service and its operational responsibilities to remain separate from Longhorn’s share-manager pods.
- Your design accounts for the NFS server and network as dependencies, along with the provisioner used to expose storage through Kubernetes.
Neither option is inherently faster, cheaper, or more reliable for every cluster. The official documentation establishes architecture and requirements, not comparative performance or cost for an unspecified environment. Make the decision against the actual workload, cluster, server and network failure domains, and recovery objectives.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
