This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "". The branch, master has been updated via c0ba5873ed94bf412416f0aa96b40304132b5cf0 (commit) from f73e7e567b8a1a53c364b9ec4288b50ee17521ab (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- commit c0ba5873ed94bf412416f0aa96b40304132b5cf0 Author: Phil Carns <[email protected]> Date: Mon Oct 29 10:18:14 2012 -0400 fix some text ----------------------------------------------------------------------- Summary of changes: .../simulation-2012-10/simulation-2012-10.txt | 45 ++++++++++--------- 1 files changed, 24 insertions(+), 21 deletions(-) Diff of changes: diff --git a/code/doc/resilience/simulation-2012-10/simulation-2012-10.txt b/code/doc/resilience/simulation-2012-10/simulation-2012-10.txt index efccebe..d5caa87 100644 --- a/code/doc/resilience/simulation-2012-10/simulation-2012-10.txt +++ b/code/doc/resilience/simulation-2012-10/simulation-2012-10.txt @@ -158,10 +158,11 @@ These algorithms and their trade offs will be discussed in greater detail in === Simulation -The key components of the Triton ROSS model are the network devices, disk -devices, and storage protocols. In this report we focus on the activities +n this report we focus on the activities that servers perform following a failure and therefore do not model client -processes or applications. +processes or applications. The key components of the Triton ROSS model are +therefore the the network devices, disk devices, and storage protocols used +by the servers. The network model is a simple cost model based on the startup cost (latency) of the network and the bandwidth (cost per byte transferred) @@ -178,6 +179,15 @@ The disk, like the network, is modeled based on the startup cost (average seek time) and bandwidth (cost per byte transferred). However, the disk is not full duplex. Reads and writes are all serviced sequentially. +The storage protocol used by Triton uses a "pull" model in which rebuilding +servers request data from surviving replicas until they have reconstructed +all necessary replicas. Each data transfer includes both a request and +acknoledgement in addition to the actual data payload itself. Requests and +acknowledgements will be transmitted using traditional two-sided messages, +while the data payload will be transmitted using one-sided RDMA put +operations. + + [[fig-triton-sim]] .State machine illustrating steps in the rebuild request model. Pipelining is not shown. [graphviz,triton-sim.png] @@ -211,26 +221,19 @@ digraph triton_sim { } ------------------------------------ -<<fig-triton-sim>> illustrates the steps involved in transferring a single data -buffer between two servers as part of reconstruction. We assume that the -rebuilding server (shown in red nodes) begins with complete knowledge of -which objects must be transferred to regain the appropriate replication -level for all objects in the system and focus on the actual data transfers -in the reconstruction process. Rebuilds are carried out using a -"pull" model, in which the rebuilding server explicitly requests data from -peer servers. The nodes shown in blue represent steps carried out on the -server that is responding to a rebuild request. - -The buffer in question is read from disk on the responding server and written -to disk on the rebuilding server. -Note that each transfer requires three messages: a request, a buffer -(payload) transfer, and a response. The buffer transfer is assumed to be -carried out using an RDMA network operation. The rebuilding server cannot -write to disk until it has received both the data buffer and the -response. +<<fig-triton-sim>> illustrates the steps involved in transferring a +single data buffer between two servers during the rebuild process. +We assume that the rebuilding server (shown in red nodes) begins with +complete knowledge of which objects must be transferred. The nodes shown +in blue represent steps carried out on the server that is responding +to a rebuild request. The buffer in question is read from disk on +the responding server and written to disk on the rebuilding server. +As described earlier, each transfer requires three messages: a request, +a buffer (payload) transfer, and a response. The rebuilding server cannot +write to disk until it has received both the data buffer and the response. Each server limits the total amount of memory used for sending and receiving -data payloads as a form of throttling to insure that servers are not +data payloads in order to insure that servers are not overwhelmed by incoming data messages. For clarity, the <<fig-triton-sim>> does not show pipelining. In practice, hooks/post-receive --