1. Ivy: A Read/Write Peer-to- Peer File System A.Muthitacharoen, R. Morris, T. Gil, and B. Chen Presented by: Matthew Allen

2. Introduction A Co-operative file system where multiple users can share a directory structure Data is stored on distributed hosts Built on DHash (Chord with some modifications)

3. I-Nodes File Attributes Data Index Disk Chord Ring Concurrent access is a problem NameBlock Security and integrity are a problems

4. Logs Log Head Write 536 2 Link 536 2 “tmp” Inode File 536 Log Records Log head is equivalent to a username and has a key derived from its owner’s public key Log records are immutable records keyed on a content hash that store all the operations the user has performed NewOld End

5. Views and Combining Logs AthieRobbieThomBenjie View Block Root I-number = 2 Participant List A3A2A1R3R2T1T2R1B1 A3 A2 A1 R3 R2T1 T2 R1 B1 NewOld Conflicts are possible!

6. Snapshots Athie Robbie Thom Benjie A4A3A2A1 B3B2B1 T1T2T3T4 root D1F1F2 F3F4D2 F5F6

7. Other Issues Security: Can always fall back on logs Cache consistency: Cache is updated from DHash on all reads, but it withholds writes until there is a close Concurrent operations: Can occur on writes and partitions, and must be resolved explicitly with “lc” Exclusive create: directory modifications need to be synchronized, so two-phase commits are used

8. Results: Single user LAN Used the (Modified) Andrew Benchmark to drive the simulation Compared a local Ivy server with an NFS server connected via 100Mb LAN Ivy is 150% slower, with Compile and Write/Create being the most expensive costs Ivy uses 8.8Mb to manage the 1.6Mb generated by the MAB

9. Results: Single user WAN 3 Ivy servers with RTT of 9, 16, and 82 ms and 79 ms to NFS Operations dominated by time to collect three log heads, which are stored on each of the servers Performance for Ivy is about 30% worse, and dominated by Write/Create and Mkdir Local computer sends 7Mb to Ivy

10. Other Results Many logs do not seem to change the results of the last simulation Using between 8 and 32 DHash servers on random planetlab hosts, the performance does not change dramatically (20% degradation from best to worst) With 32 DHash servers and multiple instances of the MAB running on different hosts, degradation is less than linear

11. Other Results II Snapshot intervals, not surprisingly, have a huge impact on the performance With 4 log heads, 1 MAB instance, and 32 DHash servers, the average time to complete the MAB almost doubles when the number of logs between snapshots goes above 70 CVS works poorly on IVY because it reads lots of files on each commit