kerneltime commented on PR #10943:
URL: https://github.com/apache/ozone/pull/10943#issuecomment-5187408064

   Correction to my review above, on the HDDS-16092 note at the end.
   
   I claimed the reachable outcome of that bug is "a deterministic startup 
crash-loop" via the updateID guard in `WithObjectID.Builder.validate`. I have 
since run the end-to-end check and it does not reproduce. Staging exactly that 
state on a real OM — wrote keys repeatedly so objects were multi-touched, 
stopped the OM, rewrote `TRANSACTION_INFO_KEY` offline from `(t:1, i:22)` back 
to `(t:1, i:16)`, restarted — the OM came up cleanly, no replay failure, data 
intact.
   
   I had verified the guard exists but never that a restart reaches it, and I 
should not have stated a consequence I had only traced on paper. HDDS-16092's 
description is corrected and carries the experiment.
   
   The mechanism itself is unaffected: the two writers of that key are 
unordered and the persisted index can move backwards over committed data. 
Nothing in the review above depends on the consequence claim — points 1 through 
6 stand as written.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to