a low-bandwidth network file system
DESCRIPTION
A LOW-BANDWIDTH NETWORK FILE SYSTEM. A. Muthitacharoen, MIT B. Chen, MIT D. Mazieres, New York U. Highlights. A file system for slow or wide-area networks Exploits similarities between files or versions of the same file - PowerPoint PPT PresentationTRANSCRIPT
A LOW-BANDWIDTHNETWORK FILE SYSTEM
A. Muthitacharoen, MIT
B. Chen, MIT
D. Mazieres, New York U
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
Working on slow networks
• Can work with local copies– Must then worry about update conflicts
• Can use remote login– Only for text-based applications
• Should use instead a low-bandwidth file system– Better than remote login– Must then deal with issues like big autosaves
blocking the editor for the duration of transfer
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 their hash values
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
• Provides close-to-open consistency– Same as Coda (and newer versions of NFS)
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
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
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 containing
new data
Identifying Similar Data Chunks
• LBFS uses collision-resistant property of SHA-1 hash function – Assumes no hash collisions
• Central challenge is – Keeping the index a reasonable size– Dealing with shifting offsets
The Case against Fixed-Size Blocks
File F
File F afteran insertion
The two files do not have a single block in common
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
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 region
of the file– Uses Rabin’s fingerprints to select
boundary regions or breakpoints
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
How it works
A file X partitioned into three chunks
Same file X after one insertion inside middle chunk
Chunk boundaries are arbitrary and identifiedby the content of their boundary regions
New Chunk
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."
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"
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"
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
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
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 keep this database up to date?– Must update it whenever file is updated– Can still have problems with local updates at
server site– Crashes can corrupt database contents
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
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
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
An example (I)
Time
Server
Alice
Requests alease
During duration of lease
Alice controls the file
Must now
renew it
An example (II)
Time
Server
Alice
Got alease
During duration of lease
Alice controls the file
Bob
Also requestsa lease
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
File Consistency
• LBFS– Caches entire files– 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
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
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
Implementation
• Some problems with the way NFS allocatesi-node numbers
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
Evaluation (II)
First four bars of each workload show upstream bandwidth, second four downstream bandwidth
Conclusions
• LBFS bandwidth usage is one order of magnitude less than conventional file systems