Advanced Topics in Operating Systems

Advanced Topics in Operating Systems

This course explores current research and engineering challenges at the intersection of operating systems, storage, and distributed computing. It is structured in two parts.

The first part consists of six lectures on selected topics, including systems benchmarking and performance evaluation, ad-hoc file systems, distributed locking, and caching strategies. Some of these sessions are held in an inverted-classroom format: students prepare the material in advance using provided readings and recordings, and class time is devoted to discussion, problem solving, and deeper analysis. This part concludes with a mid-term exam. Passing the mid-term exam is a prerequisite for admission to the second part of the course.

The second part is strongly hands-on. Working in small teams, students apply modern machine learning methods to an existing ad-hoc file system: first to analyze its behavior and performance characteristics based on traces, metrics, and workload data, and subsequently to optimize it by developing and evaluating data-driven improvements, e.g., in caching, prefetching, or data placement. To support the development work, participants in the project phase receive a license for Claude Code, an agentic AI coding assistant, for the duration of the course. The project phase concludes with a presentation and a written report in which students document their approach, experimental setup, and results.

By the end of the course, students will be able to design and conduct rigorous performance evaluations of systems software, understand the design space of ad-hoc file systems and distributed coordination mechanisms, and apply ML techniques to real-world systems optimization problems.

The final grade will consist of the best score out of two midterm exams along with a final presentation. One of the midterm exams must be passed in order to qualify for part 2 of the lecture. The dates are as follows:

Midterm 1 - 20.11.26 @ 8:30 (Lecture Slot)

Midterm 2 - TBD

Final Presentation - TBD

Prerequisites: a solid background in operating systems and systems programming (C/C++ or Rust); basic familiarity with Python and machine learning is helpful but not required.

If you have any questions don't hesitate to send an email to Andrew Geyko (andrew.geyko@uni-saarland.de)

 

Lectures take place every Friday from 8:30-10:00 in Gebäude E1 3 - Hörsaal I (0.01.1). Tutorials take place Mondays 11:30-13:00 and Thursdays 11:00-12:30 in E1.1 Room 1.21.

Lecture 1 – Performance Evaluation (October 23, 2026)

How to measure a system so that the numbers mean something. The first half covers choosing metrics, micro- vs. macro-benchmarks, standard suites, and Gernot Heiser’s catalogue of benchmarking crimes; the second half the profiling toolbox (perf, flame graphs, performance counters, eBPF), sources of measurement noise, and the statistics needed to tell a real effect from noise.

The slide deck, as well as all following materials designed by us, is available under Information → Materials.

Lecture 2 – Parallel File Systems I: PVFS (inverted classroom, October 30, 2026)

The first inverted-classroom session discusses a basic parallel file system, PVFS, and its implementation choices: striping files across I/O nodes, a single metadata manager, a user-level design over TCP, and the deliberate absence of caching and locking. In class we examine what these choices buy, what they cost, and where they stop scaling, the questions later systems in this course answer differently.

Preparation: read the paper P. Carns, W. Ligon, R. Ross, R. Thakur, PVFS: A Parallel File System for Linux Clusters, 4th Annual Linux Showcase & Conference, 2000 (https://www.usenix.org/conference/als-2000/pvfs-parallel-file-system-linux-clusters). Write a short, fixed-format reading response for yourself: the paper’s main claim in two sentences; the one design decision you found most surprising or questionable; one thing you didn’t understand; one question you’d want to ask the authors. Bring it to class, it is the basis for the discussion.

Reading guide: after reading the paper, you should be able to compute which I/O node holds a given byte of a file; explain what PVFS gains and loses by having neither client caching nor locking; say when a single metadata manager stops being acceptable; explain what the strided access via offset, gsize and stride in Section 3.3 solves that plain POSIX reads and writes do not; and explain how the three APIs reach the client library and why a kernel module was added anyway.

Optional background: the paper assumes you know what MPI and MPI-IO are. If you don’t, ten minutes each on the first two sections of the Wikipedia article on the Message Passing Interface (https://en.wikipedia.org/wiki/Message_Passing_Interface) and on the MPI-IO page of the Digital Research Alliance of Canada (https://docs.alliancecan.ca/wiki/MPI-IO), which explains file views with a short code example, is enough.

Pre-class exercise: A file is created with ssize = 64 KiB, pcount = 8 and base = 2 on a cluster with 10 I/O nodes (0–9). (a) Which I/O node holds byte 1,000,000? (b) How many I/O nodes does a 1 MiB read at offset 3 MiB touch, and how many stripes does each serve?

 

Lecture 3 - Parallel File Systems II: GPFS (inverted classroom, November 6, 2026)

The second inverted-classroom session moves to IBM’s GPFS, a shared-disk file system in which every node accesses every disk directly and consistency is maintained by distributed locking rather than by routing I/O through servers. Where PVFS avoided caching and locking altogether, GPFS caches everywhere, guarantees single-node POSIX semantics across the cluster, and shows what it takes to make distributed locking scale: byte-range tokens, dynamically elected metanodes, segmented allocation maps, and per-node write-ahead logs on shared disk for recovery. In class we examine where each of these mechanisms pays for itself and where it breaks down.

Preparation: read the paper F. Schmuck, R. Haskin, GPFS: A Shared-Disk File System for Large Computing Clusters, USENIX FAST 2002 (https://www.usenix.org/conference/fast-02/gpfs-shared-disk-file-system-large-computing-clusters). Write a short, fixed-format reading response for yourself: the paper’s main claim in two sentences; the one design decision you found most surprising or questionable; one thing you didn’t understand; one question you’d want to ask the authors. Bring it to class, it is the basis for the discussion.

Reading guide: after reading the paper, you should be able to trace the byte-range token negotiation between two or more nodes writing sequentially to the same file and explain why, without sharing, it costs no more than whole-file locking; explain what false sharing is, why GPFS rounds tokens to block boundaries, and what data shipping does differently; explain how the metanode lets many nodes write to one file without inode lock conflicts while a stat() on another node still sees the correct size; explain how the segmented allocation map and the allocation manager’s hints avoid lock conflicts on allocation; explain what happens after a node failure and why lock tokens of the failed node are released only after log recovery; and contrast the shared-disk architecture with PVFS’s I/O-node design, naming what each assumes about the hardware.

Optional background: the paper assumes you know what a storage area network (shared disks reachable from every node over a fabric) and write-ahead logging (journaling, as in ext4 or databases) are. If either is new to you, ten minutes on each term is enough.

Pre-class exercise: A GPFS file system uses 256 KiB blocks. (a) Node A opens a 2 GiB file and writes sequentially from offset 0. Node B then starts writing sequentially at offset 1 GiB while A is still writing. Which byte-range token does each node hold after B’s first write? (b) Node C now starts writing sequentially at offset 512 MiB. Which ranges do A, B and C hold afterwards, and how many messages to the token manager did C’s first write need? (c) Eight nodes write 64 KiB records to the same file in the strided pattern of Figure 3 (node 0 writes records 0, 8, 16, …; node 1 writes 1, 9, 17, …). How many nodes write into block 0, and what does that do to the token traffic?