Gargi-jais11 commented on PR #10109: URL: https://github.com/apache/ozone/pull/10109#issuecomment-4428934823
> > In-place updates to several fields are atomic under the write lock > > It cannot be under the write lock. If write lock is feasible, this jira is no longer needed. When I said in-place updates to several fields are atomic under the write lock, I meant only the phase where we would swap **metadataPath / chunksPath / volume (etc.) on the existing object** — not the full DiskBalancer copy. The entire copy obviously cannot run under the container write lock; that was never the proposal. You’re still right about the harder issue: many call sites read `KeyValueContainerData` paths (and related state) without holding the container read lock. So even if those field writes are done under writeLock(), we don’t get a clean story for unsynchronized readers (visibility / torn reads). That’s a big part of why the in-place approach felt fragile in practice. Given that, I’m staying with the re-fetch / acquireContainerLock + retry direction for this JIRA instead of mutating paths in place on the live object. -- 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]
