[
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: [email protected]
For additional commands, e-mail: [email protected]
