[ 
https://issues.apache.org/jira/browse/HDDS-14982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Wei-Chiu Chuang updated HDDS-14982:
-----------------------------------
    Attachment: Gemini_Generated_Image_bbm7jtbbm7jtbbm7.png

> [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 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).



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to