Skip to content

Conversation

@tanvipenumudy
Copy link
Contributor

@tanvipenumudy tanvipenumudy commented Jun 5, 2025

What changes were proposed in this pull request?

  • This change adds a persisted replicatedSizeOfFiles field to NSSummary to track the total expected replicated size of a directory's sub-files.
  • The value is dynamically updated upon PUT and DELETE key events.
  • The endpoint: /keys/deletePending/dirs is also updated to include the replicated size information.

What is the link to the Apache JIRA

https://issues.apache.org/jira/browse/HDDS-13180

How was this patch tested?

Manual Testing:

bash-5.1$ ozone sh volume create vol1
bash-5.1$ ozone sh bucket create vol1/buck1 --layout=FILE_SYSTEM_OPTIMIZED
bash-5.1$ ozone fs -mkdir -p ofs://om/vol1/buck1/dir1/dir2/dir3

# Create 1 MB file:
bash-5.1$ dd if=/dev/zero of=test.txt bs=1M count=1
bash-5.1$ ozone fs -put test.txt ofs://om/vol1/buck1/dir1/file1
bash-5.1$ ozone fs -put test.txt ofs://om/vol1/buck1/dir1/dir2/file2
bash-5.1$ ozone fs -put test.txt ofs://om/vol1/buck1/dir1/dir2/dir3/file3

Directory structure:

dir1/
    ├── file1 (1 MB)
    └── dir2/
        ├── file2 (1 MB)
        └── dir3/
            └── file3 (1 MB)

# Recursively delete top-level directory:
bash-5.1$ ozone fs -rm -r ofs://om/vol1/buck1/dir1

GET /api/v1/keys/deletePending/dirs/:

{
  "lastKey": "/-9223372036854775552/-9223372036854775040/-9223372036854767870/250608184600/-9223372036854751487",
  "replicatedDataSize": 9437184,
  "unreplicatedDataSize": 3145728,
  "deletedDirInfo": [
    {
      "key": "250608184600",
      "path": "vol1/buck1/.Trash/hadoop/250608184600",
      "inStateSince": 1749408310990,
      "size": 3145728,
      "replicatedSize": 9437184,
      "replicationInfo": {
        "replicationFactor": "ONE",
        "requiredNodes": 1,
        "minimumNodes": 1,
        "replicationType": "RATIS"
      },
      "creationTime": 1749408437900,
      "modificationTime": 1749408437900,
      "isKey": false
    }
  ],
  "status": "OK"
}

Unreplicated size: 3145728 (3 MB)
Replicated size (RATIS THREE): 9437184 (9 MB)

@tanvipenumudy tanvipenumudy marked this pull request as draft June 5, 2025 18:03
@tanvipenumudy tanvipenumudy marked this pull request as ready for review June 5, 2025 19:20
@ivandika3 ivandika3 added the recon label Jun 6, 2025
Copy link
Contributor

@devabhishekpal devabhishekpal left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @tanvipenumudy for this patch.
I think this might need an upgrade handler in case the user is upgrading Recon.
Currently we do not have a handler in the traditional way like it is present for other DerbyDB tables.

In this case you would have to trigger a fresh build of NSSummary after upgrade to ensure that the new changes are reflected.

@ArafatKhan2198 could you help out with how this can be done?

Copy link
Contributor

@devabhishekpal devabhishekpal left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @tanvipenumudy, overall the patch looks good to me.
Added a few minor comments.

The only thing missing right now is the upgrade handler for this patch.

@ArafatKhan2198 @devmadhuu could you help with taking a look at this patch as well?
Thanks

@tanvipenumudy tanvipenumudy marked this pull request as draft June 25, 2025 08:56
@tanvipenumudy tanvipenumudy changed the base branch from master to HDDS-13177 June 25, 2025 08:59
@tanvipenumudy tanvipenumudy marked this pull request as ready for review July 7, 2025 07:19
@tanvipenumudy tanvipenumudy marked this pull request as draft July 7, 2025 08:45
@tanvipenumudy tanvipenumudy marked this pull request as ready for review July 8, 2025 10:19
@tanvipenumudy tanvipenumudy requested a review from ChenSammi July 9, 2025 04:57
@tanvipenumudy
Copy link
Contributor Author

TestReconInsightsForDeletedDirectoriesEC passes locally, performing a rerun!

@devabhishekpal
Copy link
Contributor

Thanks for the changes @tanvipenumudy. Could you add tests for the upgrade handler as well?

Copy link
Contributor

@sumitagrawl sumitagrawl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

ReconNamespaceSummaryManager nsSummaryManager = injector.getInstance(ReconNamespaceSummaryManager.class);
ReconOMMetadataManager omMetadataManager = injector.getInstance(ReconOMMetadataManager.class);
LOG.info("Starting full rebuild of NSSummary for REPLICATED_SIZE_OF_FILES upgrade...");
nsSummaryManager.rebuildNSSummaryTree(omMetadataManager);
Copy link
Contributor

@ChenSammi ChenSammi Jul 14, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@tanvipenumudy , what's the estimation time of this rebuild process for a Recon DB, size similar to some of user bigger users?

If the upgrade will take hours, is it accepted? @devmadhuu

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe something similar was done (tree rebuild process was triggered) when the parentId field was newly introduced (PR: #6492). Not sure if we have any existing numbers on this cc: @ArafatKhan2198.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As per an offline discussion with @ArafatKhan2198, please find the stats below based on a previous benchmark:

  • Total Data: 1.347 TB
  • Directories: 5.7 million
  • Keys: 8.7 million
  • Tree Depth: 5-10 levels

The total time it took to (re)build the NSSummary tree was ~5 mins.

Copy link
Contributor

@ChenSammi ChenSammi Jul 17, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @tanvipenumudy for the info. The Recon DB is 1.347TB for 5.7m dirs and 8.7m keys? The DB size is just beyond the expectation.
Currently "nsSummaryManager.rebuildNSSummaryTree(omMetadataManager)" is a blocking call. It returns when the rebuild finished.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about if we trigger rebuild as an async operation because we have plans to show the status update of recon tasks on Overview page if they are in progress. This may ease upgrade process efficient and quicker...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you @devmadhuu, as discussed this change can be part of HDDS-13443!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The Recon DB is 1.347TB for 5.7m dirs and 8.7m keys? The DB size is just beyond the expectation.

@ChenSammi, I believe this is the total cluster capacity (please correct me if I'm wrong @ArafatKhan2198).

"nsSummaryManager.rebuildNSSummaryTree(omMetadataManager)" blocks hours during Recon update, will there be any impact to Recon's other part functionality?

Thank you @devmadhuu and @ArafatKhan2198 for clarifying the second half of the question!

@tanvipenumudy tanvipenumudy marked this pull request as ready for review July 16, 2025 08:15
Copy link
Contributor

@devmadhuu devmadhuu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@tanvipenumudy , can you check a comment pls ?

ReconNamespaceSummaryManager nsSummaryManager = injector.getInstance(ReconNamespaceSummaryManager.class);
ReconOMMetadataManager omMetadataManager = injector.getInstance(ReconOMMetadataManager.class);
LOG.info("Starting full rebuild of NSSummary for REPLICATED_SIZE_OF_FILES upgrade...");
nsSummaryManager.rebuildNSSummaryTree(omMetadataManager);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about if we trigger rebuild as an async operation because we have plans to show the status update of recon tasks on Overview page if they are in progress. This may ease upgrade process efficient and quicker...

@tanvipenumudy
Copy link
Contributor Author

tanvipenumudy commented Jul 18, 2025

we trigger rebuild as an async operation because we have plans to show the status update of recon tasks on Overview page if they are in progress.

Thank you @devmadhuu for the review. If we look at the parentID addition in NSSummary (PR: #6492), the rebuild was triggered at a different stage and in this case, the flow for rebuild via the upgrade handler is completely different - so as per our offline discussion, HDDS-13443 should be a good starting point for providing a single point of control for triggering the NSSummary tree rebuilds in Recon.

Copy link
Contributor

@ArafatKhan2198 ArafatKhan2198 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM +1
Thanks a lot for working on this @tanvipenumudy.

@ChenSammi
Copy link
Contributor

ChenSammi commented Jul 21, 2025

Hi @ArafatKhan2198 , @devmadhuu do you have any idea if "nsSummaryManager.rebuildNSSummaryTree(omMetadataManager)" blocks hours during Recon update, will there be any impact to Recon's other part functionality?

@devmadhuu
Copy link
Contributor

Hi @ArafatKhan2198 , @devmadhuu do you have any idea if "nsSummaryManager.rebuildNSSummaryTree(omMetadataManager)" blocks hours during Recon update, will there be any impact to Recon's other part functionality?

@ChenSammi nsSummaryManager.rebuildNSSummaryTree(omMetadataManager) call may take sometime. It depends on the size of OM metadata. But we have tested with few varying size of DBs (ranging from 80G till 148 GB). It may take from ~2 to 4 hours. But this was when we had ACL bloat issue. So if keeping that aside, it can come down from ~20 mins to 1 hour.

@ArafatKhan2198
Copy link
Contributor

Hi @ArafatKhan2198 , @devmadhuu do you have any idea if "nsSummaryManager.rebuildNSSummaryTree(omMetadataManager)" blocks hours during Recon update, will there be any impact to Recon's other part functionality?

@ChenSammi nsSummaryManager.rebuildNSSummaryTree(omMetadataManager) call may take sometime. It depends on the size of OM metadata. But we have tested with few varying size of DBs (ranging from 80G till 148 GB). It may take from ~2 to 4 hours. But this was when we had ACL bloat issue. So if keeping that aside, it can come down from ~20 mins to 1 hour.

Quick Facts about the DB I recently tested at :

  • Total Directories: 168 million
  • Total Keys: 237 million
  • Time to build the tree: Reprocessing for NSSummaryTaskWithFSO completed in 11,957,113 milliseconds (~3 hours, 19 minutes, 17 seconds).

cc: @ChenSammi @tanvipenumudy

Copy link
Contributor

@devabhishekpal devabhishekpal left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @tanvipenumudy.
This LGTM, +1

@tanvipenumudy
Copy link
Contributor Author

Thank you @devabhishekpal, @ChenSammi, @devmadhuu, @ArafatKhan2198, @adoroszlai and @sumitagrawl for reviewing the patch!

@tanvipenumudy tanvipenumudy merged commit 01cf373 into apache:HDDS-13177 Jul 22, 2025
42 checks passed
priyeshkaratha pushed a commit to priyeshkaratha/ozone that referenced this pull request Oct 7, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

8 participants