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 cf8d8aa673e5b6453552595a7fbe8e3f640cedb2 (commit) from c552472cb9f0ed25add75de7a1ffa33279633aec (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 cf8d8aa673e5b6453552595a7fbe8e3f640cedb2 Author: Phil Carns <[email protected]> Date: Tue Jun 5 09:44:53 2012 -0400 update example in comments ----------------------------------------------------------------------- Summary of changes: code/src/replicated-osd/rosd.aer | 26 ++++++++++++++++++-------- 1 files changed, 18 insertions(+), 8 deletions(-) Diff of changes: diff --git a/code/src/replicated-osd/rosd.aer b/code/src/replicated-osd/rosd.aer index 9d8a045..5c66e19 100644 --- a/code/src/replicated-osd/rosd.aer +++ b/code/src/replicated-osd/rosd.aer @@ -40,7 +40,8 @@ * not exist? */ -/* TODO: think about what happens in this scenario: +/* example scenario (documenting for future reference): + * * - client issues a remove() to a 3-way replicated object * - first 2 replicas delete * - 3rd server fails @@ -48,14 +49,23 @@ * server * - 4th server has not started recovery yet * - * I'm not sure that there is a way to guarantee that the 4th server will be - * in recovery when we hit it. Probably what needs to happen is the 1st - * server needs to go ahead and map out which servers it expects to do the - * remove, and pass that information along in the s2s requests? If the map - * changes before the operation completes, then a retryable error code can - * be sent back to the client. + * In this case, the 4th server will return EWRONGSERVER (because it is not + * aware of 3rd server failure yet), which gets propagated to client and + * client restarts the whole remove operation. * - * Think about if this needs to happen on any other request types + * If the 4th server enters recovery (either on the first attempt, or on a + * retry) then it will return EAGAIN to tell the client to try again later. + * + * In either case we rely on the fact that operations can be safely retried + * at any time. The NIID system will detect duplicate operations, and + * servers will automatically resolve inconsistencies during recovery. + * + * One thing that we have to be careful about, is that once a server becomes + * aware of a peer failure, it _must_ enter recovery before accepting _any_ + * other operations that take the failure into account. So it is Ok if it + * tries to service a few operations with an old snapshot of the system + * state, but it is not ok for it to service operations with a new snapshot + * until recovery is complete. */ /* TODO: doxygen format */ hooks/post-receive --