[
https://issues.apache.org/jira/browse/HDDS-12986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18099844#comment-18099844
]
Ritesh Shukla commented on HDDS-12986:
--------------------------------------
The interleaving described here is closed by the completeness gate under review
in HDDS-15542 (https://github.com/apache/ozone/pull/10496, commit ac5ce463d0),
which restores exactly the atomic view this issue says is missing.
{{reconcileChunksPerBlock}} now adopts the peer's BCSID only when the local
block covers every chunk in the peer's committed {{BlockData}}
({{coversPeerBlock}}). The {{getBlock}} snapshot
({{blockInputStream.getStreamBlockData()}}) carries the peer's chunk list and
BCSID in one response, so the adopted BCSID is always judged against the exact
chunk list it attests -- the stale merkle tree only determines what gets
*pulled*, never what gets *claimed*.
Walking the repro from the description:
* r2's stale tree from r1 omits c1, so c1 is not pulled this round.
* At commit time the gate compares r2's local chunks against r1's live
BlockData. If r1's putBlock (with c1, BCSID 100) has already landed, the
BlockData lists c1, coverage fails, and the BCSID is not adopted. If the
getBlock happened before r1's putBlock, the snapshot carries the old chunk list
*and* the old BCSID, so adopting after covering it is correct.
* c1 is pulled on a later round once r1's tree reflects it, and only then does
r2's BCSID advance. Data repair remains best effort throughout; only the
attestation waits for coverage.
Relationship to PR #8903 (auto-closed): that patch carried the BCSID in the
block merkle tree and aimed to drop the getBlock call. If revived as written it
would remove the BlockData snapshot the new gate relies on, so it would need an
alternative completeness oracle (e.g. the peer tree's full chunk list, which is
mutually consistent with a tree-carried BCSID). Once HDDS-15542 lands, the
remaining scope here looks like the optional getBlock-RPC optimization rather
than the correctness fix -- leaving the resolution call to the assignee.
HDDS-16011 tracks formalizing the BCSID semantics during reconciliation and
explicitly coordinates this issue.
Generated-by: Claude Code (Claude Fable 5)
> Race condition between BCSID update and container repair
> --------------------------------------------------------
>
> Key: HDDS-12986
> URL: https://issues.apache.org/jira/browse/HDDS-12986
> Project: Apache Ozone
> Issue Type: Sub-task
> Reporter: Ethan Rose
> Assignee: Aswin Shakil
> Priority: Major
> Labels: pull-request-available
>
> Right now we don't have an atomic view of the chunks the tree says are
> missing vs the BCSID we should update to if we pull those chunks. Here's an
> example:
> Replicas r1 and r2 are missing chunk c1 and have bcsid 99. r3 has all chunks
> and bcsid 100
> - r1 starts reconciling with r3
> - r1 writes c1 to container
> - r1 does putblock with bcsid 100
> - r2 starts reconciling with r1
> - r2 pulls tree from r1, which does not yet have c1
> - r2 pulls bcsid from r1, which is 100
> - r1 updates tree with c1
> - r2 pulls chunks based on the tree it already pulled, so it does not get
> c1
> - r2 updates bcsid to 100 because it had no failed chunk pulls, but it
> does not have c1 corresponding to bcsid 100.
> The easiest fix for this is to put BCSID in the block merkle tree proto (but
> not the hash). This also removes the need for getBlock calls during
> reconciliation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
