A. Arpaci-Dusseau Department of Computer ScienceCS739: Distributed Systems University of Wisconsin, MadisonA Low-Bandwdith Network File System – SOSP’011 Introduction• What is the motivation for LBFS? Why do they feel a network file system is needed?• What workloads/usage patterns does LBFS target?2 Related Work• The authors state that a number of file systems have properties that help them tolerate highnetwork latency and go on to describe AFS, leases, NFS4, and Coda, all of which we haveread in class. Do you agree with their characterization of each of these systems?3 DesignBasics• The main idea behind LBFS is to not send chunks of files that already exist on the otherside of the slow network (whether that is the client or the server). Chunks are identified bya SHA-1 hash over their content. If both the client and server have a chunk with the sameSHA-1 hash, they then assume they are the same chunk.One challenge is to figure out how a file should be divided into chunks. What are the two“strawman” proposals described in the paper? What are the pros and cons of each?• What is the related work of Rsync and how does it work? What are its limitations?• How does LBFS define a chunk? What is the expected size of a chunk? Why is this methodattractive for this domain (that is, can you explain the cases shown in Figure 1)?• What pathological cases can occur and how does LBS handle them?• The LBFS protocol performs whole file caching and attempts to minimize when a file isfetched from the server using close-to-open consistency with leases. What happens when aclient opens a file? What happens when a client closes a file? How does this compare toAFS?• Figure 2 shows the protocol for how an LBFS client fetches a file from the server. What doeach of the steps mean? What work does the server need to do and could it be avoided withdifferent assumptions? Under what conditions might LBFS perform worse than AFS?1• Figure 3 shows the protocol for how an LBFS client writes a file to the server. What doeach of the steps mean? Why does the server write to a temporary file? Why does it helpperformance that the client gets to pick the file descriptor for the temporary file?• Does the LBFS client need to try sending the whole file as in Figure 3? Could it track whichchunks are dirty locally and only worry about sending those back?Implications and Extensions• LBFS keeps the mapping of each SHA-1 hash to its chunk (file and offset) in a chunkdatabase. However, this database is treated only as a hint (i.e., it can be wrong). Whatis attractive about using the contents of the SHA-1 hash database as simply a hint? Whatextra work do the client and server need to do because of this? Do you think this is a goodtrade-off?• Will the LBFS protocol work for finding identical chunks within a single file?• LBFS assumes that there are never collisions of SHA-1 hashes. What would happen if therewas a collision? Could a malicious user exploit this in any way?• The paper explains that a covert channel exists that can leak information; specifically, amalicious client could learn that a server has specific contents in some file by measuringtiming differences for the CONDWRITE operation (even though the operation still fails ifthe user does not have permission to access that file).What exactly can the malicious client learn? Does this information leak seem worrisome toyou? Should they instead allow sharing across these chunks?4 Evaluation• What questions do you think they should answer to evaluate LBFS?• What is the point of the experiments in Table 1? Is anything discouraging? What do theresults in Figure 5 mean?• What are the workloads used for Figure 6? What is similar about all of their workloads?What is bandwidth normalized to? Are there significant bandwidth savings? Are the resultsin Figure 7 any different? Any other comparisons you would have liked to have seen?• Conclusion from Figures 8-10?5 Conclusions• What are the strengths of LBFS and the paper?• What are the weaknesses of LBFS and the