Distributed Operating Systems

Partial failure changes the operating-system model

In a distributed system one process can remain healthy while another fails or becomes unreachable. A missing reply cannot by itself distinguish a crashed server from a slow server or delayed packet. Consequently, ordinary procedure-call assumptions do not transfer to remote calls. Define which failures are tolerated, whether messages can be duplicated, and which guarantees survive a partition before choosing a protocol. These assumptions are part of the design rather than incidental implementation details.

References: 2026–27 calendar and Winter 2023 public reading-seminar alignment · Somayaji: Distributed OS public notes and readings

Remote calls, retries and idempotence

A client may time out after a server commits an operation but before the reply arrives. Retrying a non-idempotent request can apply it twice. Use operation identifiers and durable deduplication when an operation must have one logical effect. For an increment request labelled request-17, store both the committed increment and its response atomically. A repeat of request-17 returns that response. Do not claim exactly-once behaviour merely because the network API sends one request.

References: 2026–27 calendar and Winter 2023 public reading-seminar alignment · Somayaji: Distributed OS public notes and readings

Replication and consistency choices

Replicas improve availability and read capacity but introduce questions about ordering. Linearizability makes each operation appear to occur at one instant between invocation and response. Eventual consistency instead permits temporary divergence while requiring convergence under its stated conditions. A cache reading stale profile information may be acceptable; a uniqueness constraint can need stronger coordination. Analyse guarantees per operation rather than labelling an entire distributed product simply consistent or inconsistent.

References: 2026–27 calendar and Winter 2023 public reading-seminar alignment · Somayaji: Distributed OS public notes and readings

A replicated log and majority intersection

A replicated state machine executes the same agreed sequence of deterministic commands on each replica. Consensus coordinates that log despite failures. In a five-node majority system, three acknowledgements form a quorum, and any two majorities intersect. This intersection is a useful building block but requires protocol rules about leadership, terms and log selection to preserve safety. Raft is a supplementary concrete protocol for examining how these rules fit together.

References: 2026–27 calendar and Winter 2023 public reading-seminar alignment · Somayaji: Distributed OS public notes and readings

Distributed storage and naming

A distributed file service must locate data, manage metadata and decide how writes become durable. Separate namespace operations from bulk data transfer where useful: a metadata service can map a name to storage locations while clients stream blocks from storage nodes. Replication, erasure coding and checksums solve different problems. Replication alone does not detect silent corruption, and redundant storage does not replace a recovery plan for an accidentally authorized deletion.

References: 2026–27 calendar and Winter 2023 public reading-seminar alignment · Somayaji: Distributed OS public notes and readings

Coordination, leases and fencing

A lease grants temporary authority, but a paused process may resume after its lease expires. If it continues writing, it can conflict with a newer owner. A fencing token solves this only when the resource checks monotonically increasing tokens and rejects stale ones. Treat clocks and pauses as explicit assumptions. Likewise, container orchestration aims to restore desired state, but restarting a failed service does not automatically repair a corrupted transaction or revoke stale external authority.

References: 2026–27 calendar and Winter 2023 public reading-seminar alignment · Somayaji: Distributed OS public notes and readings

Worked failure trace and reading a systems paper

Trace a client write through leader acceptance, replica persistence, commit and acknowledgement. Crash the leader after commit but before acknowledgement: the client is uncertain, although the data may already be committed. This trace motivates retry deduplication and log recovery. When reading a systems paper, record its failure model, claimed invariant, workload, baseline and failure injection method. A throughput result with no failures does not establish correct behaviour during recovery or network partitions.

References: 2026–27 calendar and Winter 2023 public reading-seminar alignment · Somayaji: Distributed OS public notes and readings

Practice & worked answers

Original exercises for this guide.

Public notes & references

Course sources establish the scope above. Reference materials support the explanations; linked lecture notes and books remain with their authors.

• 2026–27 calendar and Winter 2023 public reading-seminar alignment ↗Course scope · 2026–27
• Somayaji: Distributed OS public notes and readings ↗Supplementary primary reference
• Ongaro and Ousterhout: Raft protocol and paper ↗Supplementary original research