Unit 1.7 · about 5 h
236 / 324Files, page cache, fsync, atomic rename and durability
Assume Programming's data-formats-ingestion and context-managers-exceptions units and their round-trip and cleanup exercises. A correct byte format is only the starting point: here you own publication, permissions, persistence boundaries and evidence after failure.
- explain
- implement
You can now
- Explain names, inodes, open files and directory permissions as separate filesystem state.
- Implement same-filesystem atomic replacement with checked file and directory synchronization.
- Distinguish accepted bytes, visible bytes, ordered writes and durability under a stated storage contract.
- Detect metadata inconsistency and payload corruption without mistaking detection for recovery.
Covers
- Files, directories, permissions and filesystem metadata
- Application buffering, page cache, flush, fsync and atomic rename
- Acknowledged, written, flushed and durable state boundaries
Study, in this order
4 steps
- Names, metadata and crash consistencyOperating Systems: Three Easy Pieces - selected foundations
Chapter 39, Sections 39.1 and 39.7 to 39.16; Chapter 40, Sections 40.3 to 40.4 and 40.6 to 40.7; Chapter 42, Sections 42.1 to 42.3 (other chapters linked from the book contents)
Depth · Draw directory entries, inodes and allocation bitmaps; then the data/inode/bitmap crash cases and journal commit boundary. Do not implement a filesystem.
- Integrity and its limitsOperating Systems: Three Easy Pieces - selected foundations
Chapter 45, Sections 45.3 to 45.7
Depth · Use checksum placement, misdirected/lost writes and scrubbing to separate corruption detection from redundancy-based repair.
- Durability and fsyncAlgoMaster Operating Systems - selected observation route
Accepted, Visible, Ordered, and Durable; File Durability vs. Name Durability; Durable Atomic File Replacement
Depth · Pair with https://algomaster.io/learn/operating-systems/crash-consistency: Process Crashes vs. Machine Crashes; Metadata Consistency vs. File-Content Guarantees; Safe File Replacement as a Protocol. Keep device flush contracts and synchronization errors explicit.
- File and directory synchronization contractsLinux proc and strace references
DESCRIPTION:
fsync,fdatasyncand directory entries; ERRORS;rename(2), DESCRIPTION: replacement, open descriptors and cross-filesystem failureDepth · Use https://man7.org/linux/man-pages/man2/rename.2.html for the second contract. Atomic name replacement is not a power-loss guarantee.
Focus on
- A directory maps names to inodes. Unlink removes a name; an open reference can keep data alive. Rename does not retarget existing open descriptors. Directory search permission governs traversal; directory write/search permission governs name changes, subject to sticky-bit and other policy.
- A language flush sends buffered bytes toward the kernel. Successful write can leave dirty page-cache pages; background writeback is not an application commit record.
- Set the new file's intended permissions before publication. Flush the language buffer, fsync the file, rename within the destination directory and fsync that directory before acknowledging durable publication under the filesystem/device contract.
- Journaling can preserve filesystem metadata consistency without preserving an application's multi-record invariant. A checksum detects some damage but supplies neither atomicity nor a missing good copy.
Reproduce closed-book
b'old\n' and keep a reader open. Use tempfile.mkstemp in that same directory; fchmod its descriptor to 0o600, wrap it with os.fdopen(..., 'wb'), write b'new\n'*1024, flush and os.fsync before closing it. Call os.replace(temp, state), open the directory with O_RDONLY|O_DIRECTORY and fsync that descriptor before closing it. Reopen state and compare its SHA-256 with the intended payload; assert the retained reader still reads b'old\n' and the published mode is 0600. Run it with TMPDIR set to a directory on a disk-backed filesystem (check with findmnt -T; /tmp is tmpfs on many systems and never reaches a disk): TMPDIR="$PWD" taskset -c 2 strace -o publish.trace -e trace=openat,write,fsync,rename,renameat,renameat2,close,fchmod -- python3 -I publish.py. Identify the payload write, file fsync, successful rename and directory fsync in order. Check each exception and clean only your temporary files. Record filesystem/mount, kernel, Python and strace versions. This probe verifies visibility and syscall ordering, not recovered state after power loss.Traps
- Calling close or Python flush a durability barrier, or ignoring a late fsync error and still reporting success.
- Creating the temporary file on another filesystem, where rename can fail with
EXDEV, or forgetting directory synchronization after publication. - Claiming a process kill simulates loss of the kernel page cache, or claiming a successful trace proves the drive honors its flush contract.
Practice
OSTEP `fsck.py`: metadata invariants
README Overview; -s 1 -S 1 and -s 2 -S 2 with default sizes
Before -c, traverse directory references and compare inode types, bitmaps and link counts. Identify inconsistent state, not necessarily a unique historical cause. The seed-2 answer diagnostic reverses the type-change wording; compare the initial and final inode arrays rather than trusting that sentence.
OSTEP `checksum.py`: additive, XOR and Fletcher checksums
README Overview; -s 1 -d 4 and -s 2 -d 4
Compute all three results before -c, using the script's modulo-255 Fletcher sums. Try -D 1,2 and -D 2,1 to expose order sensitivity. The README length example mistakenly uses -D; -d is length and -D is explicit data. Retain your publication trace in the section mini-project.
Self-test
-
After replacement, why can an old reader still see the old payload?
Its open file description still references the old inode. New path lookup finds the replacement inode; rename changes the namespace, not existing open references. -
Why synchronize the parent directory after fsync of the new file?
The file barrier covers its data and required metadata, not necessarily persistence of the directory entry naming it. The directory barrier covers publication under the supported filesystem contract. -
Does a metadata journal guarantee an application never reads a torn record?
No. Filesystem consistency and application consistency differ. Use a record/publication protocol with validation and a stated recovery policy. -
Can an additive byte checksum distinguish
[1,2]from[2,1]?No. Both sum to 3 modulo 256. A checksum has collision limits, and even a stronger digest cannot reconstruct lost bytes.
Completion criterion
Stop when
The replacement checksum, old-descriptor assertion and mode check pass, your trace shows both synchronization scopes, and you solve both two-seed simulator exercises without claiming power-loss recovery.
Mark passed, then open 1.8 Only mark this when you can do it without notes.Leads to
- 1.8 I/O access patterns and storage devices Measure reads without confusing page-cache hits with device service.
Resources for this unit
- Operating Systems: Three Easy Pieces - selected foundations Read Chapters 4-7, 13-15, 18-21, 36, 39-40, 42 and 45. Work from process state to address translation, devices, files, journaling and integrity. For every chapter, draw the owned state and one failure boundary instead of collecting summaries.
- AlgoMaster Operating Systems - selected observation route After OSTEP, use the matching lessons as a second explanation and recall check: fork, exec, wait, and exit; Zombies and Orphans; Signals; Context Switching; The Process Address Space; Paging; The TLB: Hits, Misses, and Invalidation; Page Faults; Copy-on-Write; mmap and Memory-Mapped Files; How malloc Works; VSZ, RSS, PSS, and What They Mean; File Descriptors; The Page Cache and Write-Back; Durability and fsync; Crash Consistency; Linux Namespaces; Control Groups; PID 1 and Signal Handling; Container Resource Failures; and the Investigating lessons. Treat quizzes as recall checks and keep your own traces as evidence.
- Linux proc and strace references Use proc(5), getrusage(2), mmap(2), fsync(2), rename(2), wait(2) and signal(7) while tracing a parent-child pipe, page faults, file publication and a resource-limit failure. Record exact commands and raw observations.
Also in this section
- MIT 6.1810 - selected xv6 process and memory labs Use Fall 2025 Lectures 1, 3-6, 8 and 10-11. Complete the util lab, one syscall task, and the page-table inspection plus ugetpid task from pgtbl. Add cow only if copy-on-write remains unclear. Keep all work in your own course checkout and stop before the full xv6 sequence.
- OSTEP homework - process, paging, disk and integrity simulators Solve process-run.py, paging-linear-translate.py, paging-policy.py, disk.py, fsck.py and checksum.py for at least two seeds each before using the answer flag. Then reproduce one prediction using strace, /proc or a small local program.
- Nand2Tetris - Projects 1 and 4 only Use Project 1 for Boolean logic and Project 4 for machine-language execution only if the binary or instruction-level entry check fails. Do not take the full course as a second systems curriculum.
- Algorithmica - Algorithms for Modern Hardware Use the Instruction-Level Parallelism, SIMD Parallelism and RAM & CPU Caches chapters for measured pipeline, branch, vectorization, bandwidth, latency and cache-line effects. The figures are the author's Zen 2 measurements at a fixed 2 GHz: predict and measure your own.
- MIT 6.S894 Accelerated Computing - Throughput Processors Use Lecture 2 for the processor model behind this section: superscalar issue, out-of-order execution, speculation and SIMD's need for coherent control. The labs run on the course's remote machines and target AVX-512 and NVIDIA GPUs, so they belong to the GPU track.
- Auto-Vectorization in LLVM Use The Loop Vectorizer Usage and Diagnostics sections for the Clang remarks the pipelines unit asks for; the Features list is optional depth.
- AlgoMaster: hardware and container storage companions Use Memory Ordering, Barriers, and False Sharing (coherence and false-sharing headings only); Huge Pages, NUMA, and ASLR (NUMA headings only); Storage Hardware; RAID Fundamentals (comparison and backup boundaries); and Container File Systems. These fill hardware and image-layer gaps outside the pool's selected OS revision lessons.