File Systems and Reliability, Two Phase Commit Section 12 File Systems and Reliability, Two Phase Commit April 21st, 2017 Taught by Joshua Don

Inode

Reliability - Definitions Transaction The smallest indivisible unit of work within our system E.g. Write X bytes to file, create new file, remove file, etc. ACID properties Properties required for reliable transactions (reliable means that our system behaves correctly, as expected) Atomicity – transaction either fully completes, or does not happen at all Consistency – a transaction must take data from one consistent state, into another consistent state. Cannot leave data in an intermediate, ”corrupted” state. Isolation – Concurrent transactions should execute properly. Their effect should be the same as if they happened sequentially. Durability – The effect of a transaction should persist despite crashes

Two Phase Commit An algorithm to coordinate transactions in a distributed system One coordinator, and many followers Ensures that a transaction either occurs for the coordinator and all followers, or not at all 2pc_handle_transaction(action): coordinator [Vote-request(action)] -> all followers each follower [Vote-commit OR Vote-abort] -> coordinator coordinator [Global-commit OR Global-abort] -> all followers all followers [Acknowledge] -> coordinator Notes If at least one follower votes to abort, the coordinator sends the global instruction to abort If ALL followers vote to commit, the coordinator sends the global instruction to commit

Two Phase Commit

Project 3 Task difficulty Buffer cache Indexed and extensible files Easy Hard Task difficulty Buffer cache Indexed and extensible files Subdirectories Synchronization (incorporated into all of the above tasks) Estimate of work required: (these do not include the student test cases) Personal: 18 files changed, 1066 changed lines Staff solution: About 1.5 times that (includes all of the ’optional’ items, very robust, etc.)

Project 3 Tips: You’ve already passed the base filesystem tests as part of project 2. For project 3 you must pass the base and the extended filesystem tests You’ll probably spend the most time debugging the persistence tests (div-vine is probably the hardest) Suggested order of implementation: 1. Buffer cache – not that hard/complicated, so good to knock out. The buffer cache will not cause any new tests to pass, but it definitely shouldn’t cause passing tests to start failing 2. Extensible/indexed files – Suggest getting very familiar with structure of indexed inode; there will be a lot of math and code in this part. After implementing this, all the growth tests should pass 3. Subdirectories – There are a couple of tricky cases here. All directory tests should pass after completing this. Synchronization should be done concurrently with the above parts You can only do #2 and #3 in parallel if you temporarily make the number of entries in new directories to be a fixed value (you can’t grow the directory without #2!)