Durability and coordination | Storage: capacity, performance, and recovery

Concept and mechanism

Redundancy protects against particular failure modes; those modes must be stated. RAID0 distributes data without redundancy against losing a member. A RAID1 mirror maintains current state, so it does not itself supply an earlier version after logical deletion. That recovery needs a suitable recoverable point or another source. In Linux MD, RAID5 or RAID6 that is both dirty and degraded presents a risk of undetectable corruption; refusal to start should not be treated as a simple delay. Preserve evidence and use specialist recovery instead of turning a force option into a routine procedure.

Guided application

Durability also requires understanding the scope of acknowledgement. On Linux, fsync on a file does not necessarily guarantee persistence of its new directory entry; this requires considering separate directory synchronization. Visibility in a listing command does not prove persistence after failure. For multiple hosts, EBS Multi-Attach provides access to the same volume without making conventional ext4 safe for independent writers. In a fictional high-availability project, validate coordination, write authority, and exclusion of the node that lost that authority. A simple file-creation check does not cover failures and concurrency. The hosts also remain dependent on the common volume being available.

IN PRACTICE

Two machines writing to the same ext4 do not demonstrate a safe cluster.

Common pitfalls

RAID as history; visibility as durability; force as repair; attachment as isolation.

Related topics: Interfaces and dependencies · Capacity and growth · Performance and measurement

Take this idea with you

Explain the tolerated failure and validate persistence and coordination in the concrete design.

Create account

Reference: Linux software RAID state and redundancy · DR Storage 2026-09; selected Linux and AWS storage behavior