[
https://issues.apache.org/jira/browse/HDDS-15661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Priyesh K updated HDDS-15661:
-----------------------------
Epic Link: HDDS-15233
> DN reports inflated pendingDeletionBytes on out-of-order delete transaction
> replay
> ----------------------------------------------------------------------------------
>
> Key: HDDS-15661
> URL: https://issues.apache.org/jira/browse/HDDS-15661
> Project: Apache Ozone
> Issue Type: Bug
> Components: Ozone Datanode
> Reporter: Priyesh K
> Assignee: Priyesh K
> Priority: Major
>
> When a datanode (DN) receives a {{DeleteBlocksCommand}} from SCM, it
> processes each {{DeletedBlocksTransaction}} through
> {{{}markBlocksForDeletionTransaction{}}}. Before writing to the
> delete-transaction table, the handler calls {{isDuplicateTransaction()}} to
> skip already-seen transactions. However, {{isDuplicateTransaction}} only
> guards against the exact-equal case ({{{}txID == deleteTransactionId{}}}). It
> deliberately passes through out-of-order replays where {{{}txID <
> deleteTransactionId{}}}, because those may arrive legitimately.
> In this out-of-order replay scenario, the transaction may already exist in
> the RocksDB delete-transaction table from an earlier command. The
> {{marker.apply()}} PUT is idempotent, so the DB write is harmless. But the
> code unconditionally incremented {{pendingDeletionBlocks}} and
> {{pendingDeletionBytes}} by the full block count of the transaction
> regardless of whether it was already counted. This caused the DN to report
> inflated {{pendingDeletionBytes}} for the container, which in turn led to
> incorrect space accounting observed in Recon and SCM.
> For out of order one we may need to do a db check to confirm whether its
> already present delete_txn table. It may introduce a db read in the flow.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
