From 431827f65eebccb40b9c45fb0b5c0e86552107c1 Mon Sep 17 00:00:00 2001 From: Scott Lystig Fritchie Date: Thu, 20 Feb 2014 19:19:16 +0900 Subject: [PATCH] Allow racing trim/fill and read-repair to simply "win". This exposes a bug in the PULSE model, now that we can have multiple successful fill/trim for the same LPN. --- prototype/corfurl/src/corfurl.erl | 17 ++++++++++++++++- 1 file changed, 16 insertions(+), 1 deletion(-) diff --git a/prototype/corfurl/src/corfurl.erl b/prototype/corfurl/src/corfurl.erl index c92a1ac..3ec0418 100644 --- a/prototype/corfurl/src/corfurl.erl +++ b/prototype/corfurl/src/corfurl.erl @@ -213,7 +213,22 @@ fill_or_trim_page([], _Epoch, _LPN, _Func) -> ok; fill_or_trim_page([H|T], Epoch, LPN, Func) -> case corfurl_flu:Func(flu_pid(H), Epoch, LPN) of - ok -> + Res when Res == ok; Res == error_trimmed -> + %% Detecting a race here between fills and trims is too crazy, + %% and I don't believe that it *matters*. The ickiest one + %% is a race between Proc A = trim and Proc B = read, + %% chain length of 2 or more: + %% Proc A: trim head -> ok + %% Proc B: read tail -> error_unwritten + %% Proc B: read head -> error_trimmed + %% Proc B: trim tail -> ok + %% Proc A: trim tail -> ?? + %% + %% The result that we want that both A & B & any later + %% readers agree that the LPN is trimmed. If the chain is + %% >2, then the procs can win some/all/none of the races + %% to fix up the chain, that's no problem. But don't tell + %% the caller that there was an error during those races. fill_or_trim_page(T, Epoch, LPN, Func); Else -> %% TODO: worth doing anything here, if we're in the middle of chain?