{[ promptMessage ]}

Bookmark it

{[ promptMessage ]}

2 motivation speculation in nfs figure 1 illustrates

Info iconThis preview shows page 1. Sign up to view the full content.

View Full Document Right Arrow Icon
This is the end of the preview. Sign up to access the rest of the document.

Unformatted text preview: iginal with saved copy, 22 returning “speculation failed” addition, our version of BlueFS provides synchronous I/O in which all file modifications are safe on the server’s disk b efore an op eration is observed to complete. Despite providing these strong guarantees, BlueFS is 66% faster than non-sp eculative NFS over a LAN and more than 11 times faster with a 30 ms delay. 2. MOTIVATION: SPECULATION IN NFS Figure 1 illustrates how Sp eculator improves distributed file system p erformance. Two NFS version 3 clients collaborate on a shared pro ject that consists of three files: A, B, and C. At the start of the scenario, each client has up-todate copies of all files cached. Client 1 modifies A and B; client 2 then op ens C and B. Client 2 should see the modified version of B since that file was closed by client 1 b efore it was op ened by client 2. When an application closes a file, the Linux 2.4.21 NFSv3 client first sends asynchronous write remote procedure calls (RPCs) to the server to write back any data for that file that is dirty in its file cache—these RPCs are necessary to provide close-to-op en consistency. After receiving replies for all write RPCs, the client sends a synchronous commit RPC to the server. The server replies only after it has committed all modifications for that file to disk. The NFS client returns from the close system call after receiving the commit reply. The commit RPC provides a safety guarantee, namely that no file modifications will b e lost due to a server crash after the file ha...
View Full Document

{[ snackBarMessage ]}