avijayanhwx commented on a change in pull request #2913:
URL: https://github.com/apache/ozone/pull/2913#discussion_r769301369
##########
File path:
hadoop-ozone/ozone-manager/src/main/java/org/apache/hadoop/ozone/om/request/key/OMKeyCommitRequest.java
##########
@@ -339,6 +339,7 @@ protected void processResult(CommitKeyRequest
commitKeyRequest,
// versioning of keys. So, this can be revisited later.
if (omKeyInfo.getKeyLocationVersions().size() == 1) {
omMetrics.incNumKeys();
+ omMetrics.incDataCommittedBytes(omKeyInfo.getDataSize());
Review comment:
Like @bharatviswa504 said, OM has a best effort "save metrics" logic to
allow it to continue counters from last stop. But, that does not save us from
ungraceful shutdowns.
If our goal is to understand & analyze rate of growth of data in the
cluster, I believe we don't need to worry about overwrites (since we can treat
overwrites also as "new load" on the cluster). If we want to track the actual
data that is currently being managed by Ozone, then I would suggest using
Recon. This is already being done for FSO data in HDDS-5305, and can be queried
at volume/bucket/dir level.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
