Siyao Meng created HDDS-16927:
---------------------------------

             Summary: SCM never deletes the checkpoint it downloads for a Ratis 
snapshot install, leaving a full DB copy in its snapshot directory per install
                 Key: HDDS-16927
                 URL: https://issues.apache.org/jira/browse/HDDS-16927
             Project: Apache Ozone
          Issue Type: Bug
            Reporter: Siyao Meng
         Attachments: 
MC-8-delete-downloaded-scm-checkpoint-after-install.patch, 
TestBugMC8CheckpointDirLeak.java

h3. Mechanism
{{SCMSnapshotProvider.getSCMDBSnapshot}} downloads the leader's checkpoint into 
the SCM Ratis snapshot directory ({{ozone.scm.ha.ratis.snapshot.dir}}), untars 
it to {{scm.db-<leader>-<time>}} and deletes only the tarball. 
{{HAUtils.replaceDBWithCheckpoint}} copies that directory into {{scm.db}} with 
{{copyDirectory}} and documents that the checkpoint is not deleted there. Its 
caller {{SCMHAManagerImpl.installCheckpoint}} deletes only the backup of the 
old DB, and {{SCMStateMachine}} deletes nothing. The failure paths do not 
delete it either: a failed secret key fetch or a {{verifyCheckpointFromLeader}} 
that catches an exception and returns null in 
{{notifyInstallSnapshotFromLeader}}, and an install that is rejected as too old 
or fails in {{installCheckpoint}}. Only the index check in 
{{HAUtils.verifyTransactionInfo}} deletes a downloaded checkpoint. SCM startup 
creates the snapshot directory but never cleans it.

h3. Trigger
Any checkpoint install on an SCM. With default settings this happens on every 
SCM added with {{--bootstrap}}: Ratis (3.3.1) sends a snapshot notification to 
a bootstrapping follower once. With {{ozone.scm.ha.ratis.log.purge.enabled}} it 
also happens each time a follower falls behind the purged log.

h3. Impact
* Each install leaves one full copy of the SCM DB on the metadata volume, and 
nothing reclaims it (run for one install per SCM; repeated installs on the same 
SCM follow from the same code, not run).
* Repeated installs need free space for the next untar and copy on the same 
volume, so the leak can eventually make an install fail for lack of space 
(argued, not run).
* No effect on correctness.

h3. Reproduction
PASS on the unmodified source, default configuration. 
[^TestBugMC8CheckpointDirLeak.java] ({{hadoop-ozone/integration-test}}) starts 
three SCMs with one held back and starts it, so it bootstraps and installs the 
leader's checkpoint. Afterwards its snapshot directory holds one 
{{scm.db-<leader>-<time>}} directory (70,399 bytes in the run), and the 
follower that the mini cluster bootstraps at startup holds one too. A passing 
test means the defect is present. With the patch all snapshot directories are 
empty after the install and the test fails at its {{hasSize(1)}} assertion.

h3. Patch
[^MC-8-delete-downloaded-scm-checkpoint-after-install.patch], against 
b0aa6475b7856d2c7f467dd3db12b9a1dd116f63. It also applies to master at 
52812559dad.

{{SCMStateMachine}} deletes the downloaded checkpoint with 
{{DBCheckpoint.cleanupCheckpoint()}} once it is not needed any more: in 
{{reinitialize}} after {{installCheckpoint}} returns or throws, and in 
{{notifyInstallSnapshotFromLeader}} when the secret key fetch fails or the 
verification returns null. A failed delete is logged and does not affect the 
install. This matches the cleanup the OM does in 
{{OzoneManager.installSnapshotFromLeader}}.

Not covered by the patch: the tar and partial directory left by a failed untar, 
the DB copies left by a rollback after a failed reload (SCM exits there), a 
checkpoint stored by {{setInstallingSnapshotData}} for which Ratis never calls 
{{reinitialize}} before the SCM stops, for example when the leader changes 
before its next install notification (code reading), and directories left by 
earlier versions or crashes, which can be deleted by hand while no install is 
running.

Covered by assertions added to 
{{TestSCMInstallSnapshot.testInstallCheckPoint}}: the checkpoint directory is 
gone after the in process install, and a checkpoint older than the applied 
index is rejected and deleted as well. Without the change the first assertion 
fails because the directory still exists. With it {{TestSCMInstallSnapshot}}, 
{{TestSCMInstallSnapshotWithHA}}, {{TestSCMSnapshot}}, 
{{TestSecretKeySnapshot}}, {{TestScmHAFinalization}} and the server-scm 
{{TestSCMStateMachine}} pass, and checkstyle is clean. This patch and 
HDDS-16924 both append to {{TestSCMInstallSnapshot.testInstallCheckPoint}}, so 
whichever lands second needs a trivial rebase.

Found by TLA+ model checking and code review of the SCM Ratis snapshot and 
checkpoint install paths under HDDS-15926, on commit 
b0aa6475b7856d2c7f467dd3db12b9a1dd116f63. Checked against HDDS issues and 
apache/ozone pull requests for duplicates before filing. The attached patch is 
a proposal for review. Generated with Specula (Claude Opus 5.5).



--
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