Henry Chen created HDDS-16357:
---------------------------------
Summary: Recon fileCount API does not normalize the fileSize query
parameter
Key: HDDS-16357
URL: https://issues.apache.org/jira/browse/HDDS-16357
Project: Apache Ozone
Issue Type: Bug
Components: Ozone Recon
Reporter: Henry Chen
Assignee: Henry Chen
The Recon endpoint GET /api/v1/utilization/fileCount returns an empty result
for any fileSize that is not an exact power of two.
File counts are stored in a histogram keyed by
(volume, bucket, fileSizeUpperBound), where the upper bound is computed by
ReconUtils.getFileSizeUpperBound(). The write path applies this normalization
in FileSizeCountTaskHelper#getFileSizeCountKey(), but the read path in
UtilizationEndpoint#getFileCounts() builds the lookup key from the raw
fileSize query parameter, so the key never matches unless the caller happens
to pass a bin boundary.
Steps to reproduce (bucket contains two 100000-byte keys, stored in bin 131072):
GET /api/v1/utilization/fileCount?volume=vol1&bucket=bucket1&fileSize=100000
-> [] (expected: count 2 in bin 131072)
GET /api/v1/utilization/fileCount?volume=vol1&bucket=bucket1&fileSize=131072
-> [{"fileSize":131072,"count":2}] (only works on an exact bin boundary)
The sibling endpoint /utilization/containerCount does normalize its parameter
via ReconUtils.getContainerSizeUpperBound(), so the two APIs behave
inconsistently.
A second, related inconsistency: when the lookup does succeed, the response
echoes the raw fileSize instead of the bin upper bound. The unfiltered branch
of the same endpoint returns key.getFileSizeUpperBound(), so the meaning of
the fileSize field in the response changes depending on whether the query
parameter was supplied.
Fix: normalize the parameter with ReconUtils.getFileSizeUpperBound() before
building FileSizeCountKey, and set the normalized value on the response.
Existing tests in TestEndpoints#testGetFileCounts only query exact bin
boundaries, which is why this was not caught.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
