A LOW-BANDWIDTH NETWORK FILE SYSTEM

1. A LOW-BANDWIDTHNETWORK FILE SYSTEM A. Muthitacharoen, MIT B. Chen, MIT D. Mazieres, New York U

2. Highlights • A file system for slow or wide-area networks • Exploits similarities between files or versions of the same file • Avoids sending data that can be found in the server’s file system or the client’s cache • Also uses conventional compression and caching • Requires 90% less bandwidth than traditional network file systems

3. Working on slow networks • Can work withlocal copies • Must then worry about update conflicts • Can use remote login • Only for text-based applications • Should use instead alow-bandwidth file system • Better than remote login • Must then deal with issues like big autosaves blocking the editor for the duration of transfer

4. LBFS (I) • Client keeps all recently accessed files in its cache • LBFS exploits cross file similarities to reduce data transfers between client and server • File server divides the file it stores into variable-size chunks • Indexes these chunks by theirhash values

5. LBFS (II) • When transferring a file between the client and the server • LBFS identifies the chunks the receiving side already has • Only transmits the other chunks • Providesclose-to-open consistency • Same as Coda (and newer versions of NFS)

6. Related work (I) • AFS used callbacks to reduce network traffic • Leases are callbacks with expiration date • Coda supports slow networks and disconnected operations through optimistic replication • Bayou and OceanStore investigate conflict resolution for optimistic updates • Lee et al. have extended Coda to support operation-based updates

7. Related Work (II) • Spring and Wetherall use large client and server caches to eliminate redundant network traffic: • Can send address of data already in cache of receiver rather than data themselves • Rsync exploits similarities between directory trees containing similar subtrees

8. LBFS Design • Key ideas: • Close-to-open consistency • Have a large persistent file cache at client • IDE disks are now large enough for that • Exploits similarities between files (and file versions) • Only transmits data chunks containingnew data

9. Identifying Similar Data Chunks • LBFS uses collision-resistant propertyof SHA-1 hash function • Assumes no hash collisions • Central challenge is • Keeping the index a reasonable size • Dealing with shifting offsets

10. The Case against Fixed-Size Blocks File F File F afteran insertion The two files do not have a single block in common

11. The Case against “Diffs” • “Diffs” are used by several UNIX utilities • Computed by comparing contents of file with another file • Very efficient • Must know which file(s) to compare to • Difficult in a file system • Obscure naming of editor buffer files and other temp files

12. Dividing Files into Chunks • LBFS • Only looks for non-overlapping chunks in files • Sets chunk boundaries based on file contents • To divide a file into chunks, LBFS • Examines every (overlapping) 48-byte regionof the file • Uses Rabin’s fingerprints to select boundary regions or breakpoints

13. Using Rabin’s Fingerprints • Polynomial representation of data in 48-byte region modulo an irreducible polynomial • Boundary regions have the 13 least significant bits of their fingerprint equal to an arbitrary predefined value • Assuming random data, expected chunk size is 213 = 8K • Method is reasonably fast

14. How it works A file X partitioned into three chunks Same file X after one insertion inside middle chunk New Chunk Chunk boundaries are arbitrary and identifiedby the content of their boundary regions

15. Another way to look at it (I) • Old File: Four score and seven years ago our fathers brought forth, a new country, conceived in liberty, and dedicated to the proposition that "all men are created equal."

16. Another way to look at it (II) • New File: Four score and seven years ago our fathers brought forth, upon this continent,a new nation, conceived in liberty, and dedicated to the proposition that "all men are created equal"

17. Another way to look at it (III) • Identify Chunks: Four score and seven years ago our fathers brought forth, upon this continent,a new nation, conceived in liberty, and dedicated to the proposition that "all men are created equal"

18. Another way to look at it (IV) • Send back to server the modified chunk: upon this continent,a new nation, conceived in liberty, in compressed form

19. Pathological cases • Having too many chunks require too much aggregate bandwidth • Very large chunks would be too difficult to send in a single RPC • Chunk sizes must be between 2K and 64K • May have to artificially insert chunk boundaries when files are full of repeated sequences

20. The chunk database (I) • The chunk database • Indexes chunks by first 64 bits of SHA-1 hash • Maps keys to (file,offset, count) triples • How to keepthis databaseup to date? • Must update it whenever file is updated • Can still have problems with local updates at server site • Crashes can corrupt database contents

21. The chunk database (II) • Best solution is to tolerate inconsistencies: • LBFS recomputes hash of any data chunk before using it • Recomputed value is also used to detect collisions • Very improbable but still possible

22. Protocol • NFS with some changes: • Uses leases to implement close-to-open consistency (callbacks with limited lifetime) • Practices aggressive pipelining of RPC calls • Compresses all RPC traffic

23. Leases • Leases are callbacks with • A limited lifetime (a few seconds) • A guarantee that server will not accept updates during lease lifetime without first notifying client • Advantages: • No problems with lost callbacks • Automatically expire when server crashes

24. Time An example (I) Server Requests alease During duration of lease Alice controls the file Must now renew it Alice

25. Time An example (II) Server Also requestsa lease Got alease Bob During duration of lease Alice controls the file Alice

26. An example • When server receives Bob's request, • It will try to contact Alice and break the lease • Alice will then flush all the blocks she had updated and invalidate the contents of her cache • If Alice does not answer, server must wait until Alice's lease expires

27. File Consistency • LBFS • Caches entire file • Implements close-to-open consistency • Client • Gets a lease first time a file is opened for read • Renews expired leases by requesting file attributes • Will then check if cached copy is still current

28. Reads and writes • Use additional calls not in NFS • GETHASH for reads • MKTMPFILE,and three other for write • Server ensures atomicity of updates bywriting them first into a temporary file

29. Security • More of an issue than in a well-controlled LAN • Uses SFS security infrastructure • Servers have public keys and authenticate themselves to clients • New Problem: • All LBFS users can check whether file system contains a specific chunk of data • Requires observing subtle timing differences

30. Implementation • Some problems with the way NFS allocatesi-node numbers

31. Evaluation (I) • Compared upstream and downstream bandwidth of LBFS with those of • CIFS (Common Internet File System) • NFS • AFS • LBFS with leases and gzip but w/o chunking • Downstream traffic benefits most of chunking

32. Evaluation (II) First four bars of each workload show upstream bandwidth, second four downstream bandwidth

33. Conclusions • LBFS bandwidth usage is one order of magnitude less than conventional file systems