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.
This commit is contained in:
parent
5edee3a2cf
commit
431827f65e
1 changed files with 16 additions and 1 deletions
|
@ -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?
|
||||
|
|
Loading…
Reference in a new issue