Parallel file systems face an inherent tension between POSIX I/O semantics — which guarantee that the result of any read or write operation reflects the most recent write to the same byte offset, regardless of which process performed it — and the scalable I/O required by HPC checkpoint/restart workloads. POSIX byte-range locking, where a process can lock a specific byte range to prevent concurrent writes from other processes, serializes I/O at the granularity of individual file offsets. For an MPI application performing a collective write where each of P processes writes N bytes at offset O + p × N, the POSIX byte-range lock acquisition for each offset range requires O(P²) lock requests in the worst case (each process acquires a lock for its write range, which must be coordinated with all other processes' overlapping ranges). The lock acquisition time at the metadata server (MDS) for Lustre scales as T_lock = T_acquire + (P − 1) × T_grant + T_release ≈ P × (T_rpc + T_ldlm + T_grant), where T_rpc is the RPC round-trip time to the MDS (approximately 20-50 μs for a local Lustre network), T_ldlm is the Lustre Distributed Lock Manager's lock grant processing time (approximately 2 μs), and T_grant is the lock grant notification time (approximately 5 μs). For P = 1,024 processes, T_lock ≈ 1,024 × (35 + 2 + 5) μs = 43 ms — during which all processes are blocked waiting for the lock — and the I/O throughput is reduced by a factor of (T_lock + T_io) / T_io. For a 4 KB write with T_io = 10 μs (a modern NVMe drive's latency for a 4 KB random write), the lock overhead dominates: throughput drops by 4,300×. The parallel file system throughput tool models the POSIX lock overhead as a scalability term T_posix_overhead = P × (T_rpc + T_ldlm × number_of_conflicts), and it recommends using collective I/O (MPI-IO's collective mode) which aggregates all processes' I/O requests at the MPI library layer, issuing a single non-overlapping write to the file system and bypassing the byte-range lock entirely.

MPI-IO's two-phase I/O strategy (also called "data sieving" in ROMIO, the most widely used MPI-IO implementation) addresses the POSIX serialization by reorganizing the write pattern. In phase 1 (the "aggregation" phase), each process sends its write request metadata (file offset and length) to the I/O aggregators — a subset of processes designated to handle the actual file I/O. In phase 2 (the "I/O" phase), each aggregator collects the data for its assigned file region from the contributing processes (via MPI_Alltoallv) and writes the contiguous region to the file system in a single large write. The two-phase approach converts P independent small writes (each requiring a lock acquire and release) into A large contiguous writes, where A is the number of aggregators (typically 4-64 for a large parallel job). The lock overhead drops from T_posix_overhead = P × T_lock to T_2phase_overhead = A × T_lock + T_exchange, where T_exchange = MPI_Alltoallv_time(P, A, average_message_size) is the inter-process communication time for the data redistribution. For P = 1,024, A = 16, and average_message_size = P/A × 4 KB = 256 KB per aggregator, T_exchange ≈ (P/A) × average_message_size / (NIC_bandwidth × A) × log2(A) = 64 × 256 KB / (100 Gbps × 16) × 4 = 64 × 2.1 ms / 16 × 4 = 33.6 ms per MPI_Alltoallv. The total two-phase overhead is T_2phase = 16 × 43 ms + 33.6 ms = 721.6 ms — better than the 43 seconds for 1,024 individual POSIX locks (T_posix = 1,024 × 43 ms = 44 seconds) by a factor of 61×. The throughput tool's MPI-IO model accepts the number of processes, the number of aggregators, the file system's lock grant latency (measured via lctl get_param ldlm.*.lock_grant_time), and the NIC bandwidth, and it reports the expected I/O throughput for ROMIO's default two-phase strategy versus POSIX individual writes, enabling operators to select the I/O method that optimizes checkpoint performance for their specific job scale.

The file system stripe count and stripe size parameters interact with the two-phase I/O strategy in a non-linear way that the tool models via the stripe alignment equation. Lustre stripes data across N_osts Object Storage Targets (OSTs) with a stripe size S_stripe (typically 1-4 MB). When an MPI-IO aggregator issues a write of size W at file offset O, the write is split across ⌈W / S_stripe⌉ contiguous OSTs starting from the OST determined by the file layout: OST_start = floor(O / S_stripe) mod N_osts. If the aggregator's write spans exactly S_stripe bytes and is aligned to a stripe boundary (O mod S_stripe = 0), each OST receives a single large write that matches the OST's preferred IO size, achieving the full OST bandwidth. If the write is misaligned (O mod S_stripe ≠ 0), the first and last OST receive partial stripes (a read-modify-write cycle), doubling the I/O latency for those OSTs. The throughput loss from misalignment is L_misalign = (N_partial_stripes / N_total_stripes) × (T_read_modify_write / T_full_write). For T_read_modify_write ≈ 2 × T_full_write (the OST must read the partial stripe, merge the new data, and write the result), and with typically 2 partial stripes per write (first and last), the loss is L_misalign = 2 / (W/S_stripe) × 2 = 4 × S_stripe / W. For S_stripe = 4 MB and W = 16 MB per aggregator (64 processes × 4 KB per process, aggregated over 16 aggregators = 256 KB per aggregator), W = 256 KB, and L_misalign = 4 × 4 MB / 256 KB = 64× — a 6,400% throughput loss from stripe misalignment. The tool's stripe optimizer computes the optimal stripe size S_opt such that S_opt = W / k where k is an integer between 4 and 64 (the Lustre recommended stripe count range), minimizing L_misalign. For W = 256 KB, S_opt = 256 KB / 4 = 64 KB (stripe count = 4), or S_opt = 256 KB / 8 = 32 KB (stripe count = 8). The tool outputs the recommended `lfs setstripe` parameters for the user's specific job configuration, enabling the operator to align the file layout with the two-phase I/O aggregated write size before the job starts.