Consistency Model¶
A consistency model defines the contract between the programmer and the system, specifying the rules under which shared data remains consistent. Adherence to the model ensures that the outcomes of read, write, and update operations are predictable and correct. While POSIX consistency is the dominant model in HPC, other consistency models are also used in real-world I/O libraries and file systems.
Currently, VerifyIO supports four consistency models, which cover most of the widely used parallel file systems.
POSIX Consistency:
The POSIX standard defines a strong consistency model that requires all writes to be immediately visible to all subsequent reads. While this model is simple to maintain in single-node environments, it is expensive to implement at scale. Nevertheless, major parallel file systems such as Lustre, GPFS, and BeeGF continue to support POSIX consistency due to its compatibility and widespread adoption.
Commit Consistency:
Commit consistency offers a relaxed model often used in user-level parallel file systems, such as UnifyFS and SymphonyFS. Here, synchronization is explicitly performed by issuing commit operations, typically by writers, to ensure data becomes globally visible. The data written prior to a commit is only visible after the commit operation completes. In practice, file systems using commit consistency may map a commit to an existing POSIX call; for example, UnifyFS uses the fsync call to signal a commit.
Session Consistency:
Session consistency, also known as close-to-open consistency, is another relaxed model that synchronizes data between processes when one process closes a file and another subsequently opens it. This model addresses cases where global visibility (ensured by commit consistency) is unnecessary, such as when only a subset of processes perform reads. Session consistency uses close and open operations to control visibility between processes.
MPI-IO Consistency:
MPI-IO, a part of the MPI standard, specifies MPI’s I/O functionalities. MPI-IO’s relaxed model ensures sequential consistency for conflicting accesses through a sync-barrier-sync construct. In this pattern, MPI_File_open, MPI_File_close, and MPI_File_sync serve as synchronization points for flushing or retrieving data, while barriers (e.g., MPI_Barrier, or point-to-point communications like MPI_Send/MPI_Recv) ensure proper ordering.