[
https://issues.apache.org/jira/browse/HDDS-14982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wei-Chiu Chuang updated HDDS-14982:
-----------------------------------
Description:
Add a system internal doc on Snapshot deletion lifecycle:
1. Request Phase: OMSnapshotDeleteRequest
* User Action: User runs ozone sh snapshot delete.
* Operation: This request only marks the snapshot's status as SNAPSHOT_DELETED
in the SnapshotInfoTable and sets the deletionTime.
* Result: It does not adjust the chain or neighbors yet. The snapshot is now a
candidate for the background service.
2. Reclamation Phase: SnapshotDeletingService
* Operation: This background service identifies snapshots with the
SNAPSHOT_DELETED status.
* Key Moving: It moves entries from the deleted snapshot's deletedTable,
deletedDirTable, and renamedTable to either:
* The next active snapshot in the chain.
* The Active Object Store (AOS) (the main bucket) if no subsequent snapshot
exists.
* Settling: Once all keys/dirs for that snapshot have been moved (i.e., the
snapshot's deleted tables are empty), the service collects the snapshot's DB
key into a "purge list".
3. Finalization Phase: OMSnapshotPurgeRequest
* Trigger: Triggered by the SnapshotDeletingService once a snapshot is "empty"
(all keys reclaimed).
* Chain Adjustment: This is where the actual chain surgery happens. It updates
the previousSnapshotId of the next snapshot in the chain to point to the
deleted snapshot's predecessor, effectively "stitching" the chain back together.
* Deep Clean Flag: It sets setDeepClean(false) on the next snapshots. This
tells the KeyDeletingService that it can now perform a "deeper" cleanup
because a snapshot in the middle of the chain has been removed, potentially
uncovering more keys to delete.
* Removal: Finally, it removes the snapshot from the SnapshotInfoTable cache
and deletes the checkpoint directory on disk.
4. Persistence: OMSnapshotPurgeResponse
* Operation: The Ozone Manager double-buffer flushes the transaction.
* Result: The snapshot record is physically deleted from the RocksDB
snapshotInfoTable.
Summary of roles:
* OMSnapshotDeleteRequest: The Labeler (marks for death).
* SnapshotDeletingService: The Reclaimer (moves the data).
* OMSnapshotPurgeRequest: The Surgeon & Janitor (re-links the chain and
deletes the record).
was:
Add a system internal doc on System deletion lifecycle:
1. Request Phase: OMSnapshotDeleteRequest
* User Action: User runs ozone sh snapshot delete.
* Operation: This request only marks the snapshot's status as
SNAPSHOT_DELETED in the SnapshotInfoTable and sets the deletionTime.
* Result: It does not adjust the chain or neighbors yet. The snapshot is now
a candidate for the background service.
2. Reclamation Phase: SnapshotDeletingService
* Operation: This background service identifies snapshots with the
SNAPSHOT_DELETED status.
* Key Moving: It moves entries from the deleted snapshot's deletedTable,
deletedDirTable, and renamedTable to either:
* The next active snapshot in the chain.
* The Active Object Store (AOS) (the main bucket) if no subsequent
snapshot exists.
* Settling: Once all keys/dirs for that snapshot have been moved (i.e., the
snapshot's deleted tables are empty), the service collects the snapshot's DB
key into a "purge list".
3. Finalization Phase: OMSnapshotPurgeRequest
* Trigger: Triggered by the SnapshotDeletingService once a snapshot is
"empty" (all keys reclaimed).
* Chain Adjustment: This is where the actual chain surgery happens. It
updates the previousSnapshotId of the next snapshot in the chain to point to the
deleted snapshot's predecessor, effectively "stitching" the chain back
together.
* Deep Clean Flag: It sets setDeepClean(false) on the next snapshots. This
tells the KeyDeletingService that it can now perform a "deeper" cleanup
because a snapshot in the middle of the chain has been removed,
potentially uncovering more keys to delete.
* Removal: Finally, it removes the snapshot from the SnapshotInfoTable cache
and deletes the checkpoint directory on disk.
4. Persistence: OMSnapshotPurgeResponse
* Operation: The Ozone Manager double-buffer flushes the transaction.
* Result: The snapshot record is physically deleted from the RocksDB
snapshotInfoTable.
Summary of roles:
* OMSnapshotDeleteRequest: The Labeler (marks for death).
* SnapshotDeletingService: The Reclaimer (moves the data).
* OMSnapshotPurgeRequest: The Surgeon & Janitor (re-links the chain and
deletes the record).
> [Docs] Snapshot deletion lifecycle
> ----------------------------------
>
> Key: HDDS-14982
> URL: https://issues.apache.org/jira/browse/HDDS-14982
> Project: Apache Ozone
> Issue Type: Improvement
> Components: documentation, Snapshot
> Reporter: Wei-Chiu Chuang
> Priority: Major
> Attachments: Gemini_Generated_Image_bbm7jtbbm7jtbbm7.png
>
>
> Add a system internal doc on Snapshot deletion lifecycle:
> 1. Request Phase: OMSnapshotDeleteRequest
> * User Action: User runs ozone sh snapshot delete.
> * Operation: This request only marks the snapshot's status as
> SNAPSHOT_DELETED in the SnapshotInfoTable and sets the deletionTime.
> * Result: It does not adjust the chain or neighbors yet. The snapshot is now
> a candidate for the background service.
> 2. Reclamation Phase: SnapshotDeletingService
> * Operation: This background service identifies snapshots with the
> SNAPSHOT_DELETED status.
> * Key Moving: It moves entries from the deleted snapshot's deletedTable,
> deletedDirTable, and renamedTable to either:
> * The next active snapshot in the chain.
> * The Active Object Store (AOS) (the main bucket) if no subsequent snapshot
> exists.
> * Settling: Once all keys/dirs for that snapshot have been moved (i.e., the
> snapshot's deleted tables are empty), the service collects the snapshot's DB
> key into a "purge list".
> 3. Finalization Phase: OMSnapshotPurgeRequest
> * Trigger: Triggered by the SnapshotDeletingService once a snapshot is
> "empty" (all keys reclaimed).
> * Chain Adjustment: This is where the actual chain surgery happens. It
> updates the previousSnapshotId of the next snapshot in the chain to point to
> the
> deleted snapshot's predecessor, effectively "stitching" the chain back
> together.
> * Deep Clean Flag: It sets setDeepClean(false) on the next snapshots. This
> tells the KeyDeletingService that it can now perform a "deeper" cleanup
> because a snapshot in the middle of the chain has been removed, potentially
> uncovering more keys to delete.
> * Removal: Finally, it removes the snapshot from the SnapshotInfoTable cache
> and deletes the checkpoint directory on disk.
> 4. Persistence: OMSnapshotPurgeResponse
> * Operation: The Ozone Manager double-buffer flushes the transaction.
> * Result: The snapshot record is physically deleted from the RocksDB
> snapshotInfoTable.
> Summary of roles:
> * OMSnapshotDeleteRequest: The Labeler (marks for death).
> * SnapshotDeletingService: The Reclaimer (moves the data).
> * OMSnapshotPurgeRequest: The Surgeon & Janitor (re-links the chain and
> deletes the record).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
