Filesystems

Writer A holds stable.lock, writer B waits at the shared lock, and an ordinary nonparticipating write bypasses the gate to data.

File locks protect a shared protocol and a specific object

A file lock coordinates participants that agree on what to lock, when to acquire it, and which operations belong inside the critical section. Linux offers several lock interfaces with different ownership and release rules. Choosing a filename and calling something named lock is insufficient: the protocol must identify the underlying object, the lock family, and the lifetime of every reference involved. ...

A candidate file fsync precedes atomic replacement of the current name; parent-directory fsync follows. The sequence emphasizes checking every result.

Fsync completes a storage request within an update protocol

A successful ordinary write(2) makes its accepted bytes available through the kernel’s file state, but does not by itself establish crash durability. fsync requests synchronization of a file’s data and associated metadata and waits for completion as reported by the storage stack. It is one operation in an update protocol. Correct ordering, checked errors, directory entries, and the storage system’s actual guarantees still matter. ...

Data moves from a language buffer to page cache and storage. A separate reader branches from page cache before the explicit fsync boundary; visibility does not prove durable completion.

Writeback separates buffered visibility from storage completion

Buffered file I/O can pass through a language buffer, the kernel page cache, and the storage stack at different times. Modified cache pages need writeback so their data reaches the backing filesystem and device. This separation can combine work and improve throughput, but it means that another reader seeing new bytes is not, by itself, evidence that a crash-safe storage boundary has completed. ...