hesela.devShared-disk file system
A shared-disk file system coordinates concurrent file access by multiple hosts that can reach the same underlying block storage.
The shared block device supplies access to bytes; the file-system cluster must coordinate metadata changes and cached state across hosts. Each participating host operates the shared-disk file system over common block storage, rather than merely consuming a remote file service [1].
GFS2 is a concrete Linux example. Its cluster-wide locking uses the Distributed Lock Manager; its glock layer manages local caching in relation to cluster locks. Relinquishing an exclusive glock requires log flushing, dirty-data writeback and cache invalidation, so access that moves between nodes can incur coordination work even when the storage is healthy [2].
Locking during normal operation and exclusion during failure recovery are separate requirements. A GFS2 cluster requires fencing to exclude a failed or isolated node from shared storage before recovery; unsuccessful fencing can leave the cluster waiting. A shared-disk file system also does not replace application-level transaction coordination [2].
Relations
- related
- File storage, Block storage, SAN, NAS, I/O fencing
Advantages
- Provides coordinated file access across hosts sharing block storage, instead of treating each mount as an independent local file system. [1]
Limitations
- Requires the cluster's locking and failure-recovery infrastructure; shared reachability by itself provides neither. [2]
- The shared storage remains a dependency: multiple attached hosts do not create independent data copies. [3]
Citations
- Red Hat Enterprise Linux 8: Overview of available file systems, local, network and shared-storage categories
- Red Hat Enterprise Linux 8: Configuring GFS2 file systems, cluster configuration, fencing and glock caching
- Amazon EBS: Multi-Attach considerations and limitations (service-specific documentation)