Added CS162 lec 22 part 1

CS162/index.md

@@ -31,4 +31,5 @@ Taught by Prof. John Kubiatowicz at UC Berkeley in Fall, 2020
 17. [Lecture 18 - General I/O, Storage Devices, Performance]({% link CS162/lec18.md %})
 18. [Lecture 19 - Filesystems 1: Performance, Queueing Theory, Filesystem Design]({% link CS162/lec19.md %})
 19. [Lecture 20 - Filesystems 2: Filesystem Design, Case Studies]({% link CS162/lec20.md %})
-20. [Lecture 21 - Filesystems 3: Case Studies, Buffering, Reliability, Transactions]({% link CS162/lec21.md %})
+20. [Lecture 21 - Filesystems 3: Case Studies, Buffering, Reliability, Transactions]({% link CS162/lec21.md %})
+21. [Lecture 22 - Transactions, End-to-End Arguments, Distributed Decision Making]({% link CS162/lec22.md %})

CS162/lec21.md

@@ -1,6 +1,6 @@
 ---
 layout: default
-title: "Lecture 20 - Filesystems 3: Case Studies, Buffering, Reliability, Transactions"
+title: "Lecture 21 - Filesystems 3: Case Studies, Buffering, Reliability, Transactions"
 parent: UCB CS 162 - Operating Systems and Systems Programming
 nav_order: 20
 ---

CS162/lec22.md

@@ -0,0 +1,18 @@
+---
+layout: default
+title: "Lecture 22 - Transactions, End-to-End Arguments, Distributed Decision Making"
+parent: UCB CS 162 - Operating Systems and Systems Programming
+nav_order: 21
+---
+
+# Transactions, End-to-End Arguments, Distributed Decision Making
+
+Transactions in a file system are a mechanism to improve the reliability of the system. They extend the concept of atomic updates from memory to persistent storage. A transaction is an atomic sequence of writes that takes the file system from one state to another. If the system crashes before the transaction is complete, none of the writes in the transaction make it through and the file system is restored to the state it was in before the transaction.
+
+Transactions are generally implemented using a log-based approach. There is a log which supports only one atomic operation - appending to it. When we write to a file as part of a transaction, all of the individual steps of the write are written as instructions in the log. Once all the instructions are written, we write a "commit" instruction to the log, which says that the transaction is complete and the changes can be applied to the file system.
+
+The OS then goes through the instructions in the log and applies them one by one. If we crash at any time before reaching the commit instruction, we just start from the first instruction and perform the writes again. This is okay because we're just overwriting the same data. If we crash before the commit message is written to the log, all the instructions for this transaction are just thrown out from the log and we say we rolled back.
+
+We use NVRAM for the log to make sure unapplied commits are not lost in case of power failures.
+
+A file system that uses a log in this way to support transactions is called a transactional file system. A transactional file system can be log structured or journaled. In a log structured file system, the data stays in log form. In a journaled file system, the log is only used for recovery and all data is written directly to the disk.