[
https://issues.apache.org/jira/browse/HDDS-7728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17763720#comment-17763720
]
Stephen O'Donnell commented on HDDS-7728:
-----------------------------------------
There is a larger problem, where if you have containers offline, and then
delete blocks from the online copy. Then later the offline replicas come back,
the deletes will not get applied to the ones that come back online.
>From that point on, the replicas will not be identical. Some extra blocks
>might be in some of the replicas. This doesn't cause a problem, except that it
>uses up some disk space.
"Missing containers" are another thing - this would be the case where all the
replicas are missing somehow, and then either they will come back again if
datanodes are fixed, or they are lost forever and will never come back. I am
not sure what happens to the delete block transactions in SCM in this second
case. Will they stay stuck in a queue in SCM, or will SCM drop them?
> Block should be safely deleted from the containers if they are instructed
> from OM and containers are in missing state.
> ----------------------------------------------------------------------------------------------------------------------
>
> Key: HDDS-7728
> URL: https://issues.apache.org/jira/browse/HDDS-7728
> Project: Apache Ozone
> Issue Type: Improvement
> Components: SCM
> Affects Versions: 1.3.0
> Reporter: Uma Maheswara Rao G
> Assignee: Ashish Kumar
> Priority: Major
>
> Currently when OM instructs to delete the blocks and if containers are in
> missing state, deletion may not be processed properly. This Jira to track
> this requirement and implement to safe deletion os blocks what ever state
> they are on. Otherwise containers would never get cleaned up even though all
> blocks in that files deleted.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
