[
https://issues.apache.org/jira/browse/HDDS-7728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17765147#comment-17765147
]
Stephen O'Donnell commented on HDDS-7728:
-----------------------------------------
> After offline discussion with Sammi Chen, We are thinking that we can add
> blockDeleteTransactionID in replica and RM can judge deleting extra replica
> based on blockDeleteTransactionID
I am not sure I am in favor of that and without more details would tend toward
being -1 on it. Is the complexity this will add really worth it, and will it
solve absolutely all cases of orphan blocks? If it will not, and we still need
an orphan block cleanup for this and other reasons, then I don't think it is
worth adding the complexity here.
Also, RM may want to base removal decisions based on the disk usage of nodes
(ie remove the replica from the node with the least free space), and it is also
constrained by placement policy. Adding another variable here starts to make
things rather complicated and there may be scenarios where it cannot honor the
lowest block delete transaction id (eg placement policy constrained).
> 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]
