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 6308dd3d836c83f4c5e7abf05f9f706778bba8e2 (commit) from 4dd9eaa60345959ee4a022afb95d497f88d62523 (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 6308dd3d836c83f4c5e7abf05f9f706778bba8e2 Author: Phil Carns <[email protected]> Date: Mon Oct 29 12:03:57 2012 -0400 fill in rough conclusions ----------------------------------------------------------------------- Summary of changes: .../simulation-2012-10/simulation-2012-10.txt | 53 ++++++++++---------- 1 files changed, 27 insertions(+), 26 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 264a0be..b0b4580 100644 --- a/code/doc/resilience/simulation-2012-10/simulation-2012-10.txt +++ b/code/doc/resilience/simulation-2012-10/simulation-2012-10.txt @@ -481,32 +481,33 @@ object IDs that must be rebuilt. == Conclusions -deliberately do not draw a conclusion about what algorithm etc. is - "best". The conclusion instead is that we have the ability to evaluate -different algorithms at scale, and that algorithmic choices can have a big -impact on design space, etc. - -== Future work - -* analysis of failure rates to set a goal for the rebuild rate in Triton -* expand simulation to account for: -** cost for clients to locate data -** cost of calculating list of affected objects -* evaluate more algorithms -* choose an algorithm or set of algorithms to implement in Triton and - validate performance -* erasure coding - - - -[[sec-background]] -== Background - -[[sec-conclusions]] -== Conclusions - -=== Future work - +In this report we have demonstrated an ability to simulate complex storage +algorithms at larger scales than can be effectively tested on existing +systems. We focused on the rebuild algorithm used by servers to reconstruct +object replicas following a failure, and in particular on the placement +algorithm used to dictate the location of each replica. Our preliminary +results show that the choice of placement algorithm can have a profound +impact on rebulid performance. + +Moving forward, we intend to analyze the projected failure rate of exascale +systems to determine how quickly a rebuild algorithm must make progress in +order to avoid data loss. Using this metric as a goal we will expand our +simulation to include additional details including the cost of locating data +on the system the cost of assembling a list of affected objects to be +rebuilt. If necessary, we will seek to identify algorithms that bridge the +gap between algorithms that distribute data widely across all servers and +algorithms that provide ease of calculation and predictable placement. +We will also validate our model using small scale experiments in the +Triton prototype to determine if we should integrate higher fidelity +network or disk models. + +Our goal is to use these simulations to guide the choice of +algorithm (or family of algorithms) used in Triton and to validate their +behavior at scale. + +Similar simulations could also be used to evaluate epidemic protocols for +fault detection and state dissemination. We also intende to explore the use +of erasure coding for quiescent data. == Bibliography hooks/post-receive --