errose28 commented on PR #3360:
URL: https://github.com/apache/ozone/pull/3360#issuecomment-1116767515

   @JacksonYao287 what is the motivation behind this change? Maintaining a 
record of all deleted containers in SCM has the following benefits:
   - If a dead node comes back online after a container is deleted and starts 
reporting a deleted container, SCM can delete it instead of falling back to the 
logic for unknown containers in `ContainerReportHandler`.
   - Easier debug-ability when working through potential HDDS bugs.
   
   I do not see problems with keeping deleted container entries. Even if we had 
to track 10 billion containers during the system's lifetime (which I suspect 
might be pushing the limits of what RocksDB can handle) that would correspond 
to about 5gb * 10billion = 50 exabytes of data deleted from the cluster during 
its lifetime, which is a massive amount of churn. If we are concerned about SCM 
memory usage since it is tracking all the containers in memory, a better 
approach might be to track deleted containers in RocksDB only.
   
   This is actually a somewhat major change in the way HDDS functions, so if we 
want to go through with this, I think we would need to answer some more 
questions:
   1. What are the specific problems/use cases where the current approach will 
cause problems?
   2. How serious are the problems with the existing approach compared to the 
potential problems of this new approach?
   3. What happens when a dead datanode comes back and starts reporting a 
container that was deleted and removed?
   4. How is case 3 reconciled with legitimate unknown containers that may be 
reported to SCM due to bugs or improper configuration?


-- 
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