Parallel PutChunk RPC calls in WriteMV #1806
Conversation
souravgupta-msft
requested review from
vibhansa-msft and
ashruti-msft
as code owners
souravgupta-msft
requested review from
syeleti-msft and
jainakanksha-msft
as code owners
| } else if slices.Contains(rvsWritten, rv.Name) { | ||
| log.Debug("ReplicationManager::WriteMV: Skipping RV %s/%s (state %s) as it was already written to: %v", | ||
| rv.Name, req.MvName, rv.State, rvsWritten) | ||
|
|
||
| common.Assert(retryCnt > 0) | ||
| common.Assert(rv.State == string(dcache.StateOnline) || | ||
| rv.State == string(dcache.StateSyncing), rv.Name, rv.State, rvsWritten) | ||
|
|
||
| // | ||
| // Skip writing to this RV, as it is previously written to. | ||
| // So, send nil response to the response channel to indicate that | ||
| // we are not writing to this RV. | ||
| // | ||
| responseChannel <- nil | ||
|
|
There was a problem hiding this comment.
it's not safe to omit replicas that were written in some prev attempt.
Imagine a replica goes from online->offline->online state during the course of one write.
When it was online the first time around we wrote a chunk, then it went offline and again joined back. This would have caused the chunk that was written, to be cleared. Now this replica doesn't have this chunk and we won't write it since as per rvsWritten we have already written that chunk.
We should consider all the replica writes corresponding to one mv write as a transaction, performed in a given cluster state (the entire write transaction must complete in one cluster state). Only when we complete a write transaction in one cluster state, we are guaranteed that if the cluster changes to some other state (one or more component RVs of this MV going offline and/or replaced by other RVs) the data will be properly sync'ed.
If all the replicas agree with the cluster state and they confirm that by not failing any replica write with NeedToRefreshClusterMap, then we can consider that write transaction as successful.
Taking some replica writes from previous cluster state and some from later ones, the entire mv write transaction cannot be considered successful.
Anyways, it's ok to repeat some component writes in the rare case of an MV changing in the middle of a write.
linuxsmiths
force-pushed
the
sourav/parallelWriteMV
branch
from
255d6cc to
5bdbfc0
Compare
Make sure RefreshClusterMap refreshes to the desired clustermap epoch.
linuxsmiths
force-pushed
the
sourav/parallelWriteMV
branch
from
910a593 to
428f521
Compare
Type of Change
Description
Send PutChunk RPC calls in parallel in WriteMV to improve performance.