Priyesh K created HDDS-15661:
--------------------------------
Summary: 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
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]
