You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ozone.apache.org by "ASF GitHub Bot (Jira)" <ji...@apache.org> on 2026/06/18 18:55:00 UTC
[jira] [Updated] (HDDS-15611) [Docs] Explain the internal workflow of key deletion with Ozone Snapshot
[ https://issues.apache.org/jira/browse/HDDS-15611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
ASF GitHub Bot updated HDDS-15611:
----------------------------------
Labels: pull-request-available (was: )
> [Docs] Explain the internal workflow of key deletion with Ozone Snapshot
> ------------------------------------------------------------------------
>
> Key: HDDS-15611
> URL: https://issues.apache.org/jira/browse/HDDS-15611
> Project: Apache Ozone
> Issue Type: Task
> Reporter: Wei-Chiu Chuang
> Priority: Major
> Labels: pull-request-available
>
> h1. Problem
> The current System Internals documentation for Key Deletion (delete.md https://ozone.apache.org/docs/next/system-internals/data-operations/delete)
> explains the basic asynchronous deletion path (moving keys to the active deletedTable and purging blocks via the KeyDeletingService ). However, it
> does not explain how key deletion behaves when Ozone Snapshots are enabled on a bucket.
> Specifically, it lacks details on:
> 1. How deleted keys are statefully partitioned between the active DB and snapshot DBs.
> 2. How the KeyDeletingService coordinates key reclaiming across active and snapshot database checkpoints.
> 3. How snapshot deletion/reclamation merges and moves deleted keys along the snapshot chain.
> Adding this workflow is essential for operators and developers to understand space/quota usage and metadata reclaim mechanics in snapshot-enabled
> buckets.
> h1. Proposed Documentation Updates
> We should update the System Internals Delete document to cover the following snapshot key deletion mechanics:
> 1. Deleted Key Partitioning at Snapshot Creation:
> • Explain that when a snapshot is taken, the active DB is checkpointed.
> • Immediately after the checkpoint is created, the snapshot creation transaction cleans up/purges all keys under the target bucket from the active
> DB's deletedTable and deletedDirTable .
> • This partitions deleted keys: keys deleted before a snapshot reside in the snapshot's local deletedTable , while keys deleted after the latest
> snapshot reside in the active DB's deletedTable , preventing double-counting and key duplication.
> 2. Reclaimable Key Filtering:
> • Explain how the KeyDeletingService and DirectoryDeletingService use the ReclaimableKeyFilter to check if a deleted key is referenced by
> prior snapshots before reclaiming its block space.
> 3. Snapshot Reclamation (Snapshot Delete):
> • Explain the workflow of snapshot deletion/purging (via OMSnapshotMoveDeletedKeysRequest ).
> • Detail how deleted keys are moved from the deleted snapshot's deletedTable to the next snapshot's deletedTable in the chain, or back to the
> active DB's deletedTable if it was the last snapshot.
> 4. Quota Maintenance:
> • Explain how snapshotUsedBytes and snapshotUsedNamespace track the space/namespace of keys pending deletion, and how the Quota Repair tool
> recalculates these metrics across all active snapshot databases.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@ozone.apache.org
For additional commands, e-mail: issues-help@ozone.apache.org