rwf-append · shipping · also per-write append

RWF_APPEND

RWF_APPEND is a Linux pwritev2 flag that requests end-of-file placement for one write operation.

Documented since Linux 4.16, this flag selects append placement without changing the open file description's O_APPEND setting. [1] [2]

A valid nonnegative offset leaves the shared current offset unchanged, even though data goes to the end of the file. Offset -1 instead updates that cursor after the transfer. Other negative offsets are rejected by the positional path. [3]

The v6.17 per-operation flag validator rejects combining RWF_APPEND and RWF_NOAPPEND. A zero-total-length write can return before that validator; an empty call is not a reliable capability probe. [2] [3]

Append placement does not validate a log after a crash. The ALICE study separates persisted file size from contents and describes recovery failures even when an incompletely persisted appended region contains zeros. This is historical crash-model evidence, not a test of RWF_APPEND. [5]

Relations

related

RWF_NOAPPEND, O_APPEND, pwrite, File offset, Open file description, Short write, writev, fsync

Advantages

• Allows append placement without toggling status flags shared by duplicated descriptors.

Limitations

• Short writes still need byte accounting and a concurrency policy for completing a logical record. [1]
• Does not by itself request synchronized completion or torn-write protection. [1]

Citations

1. Linux man-pages: readv(2), pwritev2 per-call flags and offset semantics (accessed 2026-11-11)
2. Linux v6.17: kiocb_set_rw_flags validation and per-operation append state (accessed 2026-11-11)
3. Linux v6.17: pwritev2 dispatch, current offsets and zero-length write handling (accessed 2026-11-11)
5. Pillai et al., OSDI 2014: All File Systems Are Not Created Equal, sections 2.1 and 4.4.2 (accessed 2026-11-12)

Further reading

4. Hesela: Atomic rename is not a durable commit, per-write positioning (accessed 2026-11-11)

JSON: /data/terms/rwf-append.json