LEARN. PRACTICE. GROW.Concept and mechanism
Start with the application access contract. A block device supplies storage over which other layers can organize partitions and filesystems. A shared file service provides its own interface, such as NFS. An object service organizes content through keys and API operations. Sufficient capacity does not make these interfaces interchangeable. If an application depends on POSIX paths and filesystem operations, replacing the destination with a bucket requires evaluating compatibility and adaptations. The strong read-after-write consistency documented for S3 does not turn its object API into a POSIX interface. Record required operations, writers, and dependencies before selecting the implementation.
Guided application
During diagnosis, map the application path to its mounted filesystem and underlying device. findmnt helps observe the effective mapping; a new disk existing does not prove /srv/export uses it. In a fictional batch, unique results on EC2 instance store are at risk during stop, hibernation, or termination, although they survive reboot. Validate the planned event and preserve required content. When several hosts access the same volume, do not assume multiple attachments make ext4 safe for concurrent writing. Shared access requires supported coordination, and a common volume remains a dependency for the multiple hosts.
A free new disk does not resolve a path still mounted on the old disk.
Common pitfalls
Object as POSIX file; reboot as stop; attachment as replica; path as device.
Related topics: Capacity and growth · Performance and measurement · Durability and coordination
Map interface, path, writers, and lifecycle before choosing or changing storage.
Reference: S3 object storage and consistency · DR Storage 2026-09; selected Linux and AWS storage behavior