spacemonkd opened a new pull request, #10849: URL: https://github.com/apache/ozone/pull/10849
## What changes were proposed in this pull request? HDDS-15949. Handle split MPU part counting for abort batch sizing and container-key-mapping CLI Please describe your PR in detail: #### Schema-aware MPU part counting for abort batch sizing (`OmMetadataManagerImpl.getExpiredMultipartUploads()`, `KeyLifecycleService`) For split-schema MPUs (schemaVersion == 1), part count now comes from multipartPartsTable via OMMultipartUploadUtils.countParts() instead of getPartKeyInfoMap().size() (which is always 0 for split MPUs). Without fix the expired MPU cleanup and lifecycle AbortIncompleteMultipartUpload treated every split MPU as having 0–1 parts when sizing abort batches. Batches could exceed the intended part limit (maxParts / mpuAbortLimitPerTask), causing larger-than-planned abort work per iteration. The abort logic itself was already schema-aware; only batch sizing was wrong. #### Shared countParts() helper (OMMultipartUploadUtils) Added countParts(omMetadataManager, uploadId) wrapping the existing cache-aware scanParts() logic. Without fix it is the same as above, plus duplicated/incorrect counting if each call site reimplemented split-table reads differently from abort/complete paths. #### Schema-aware split MPU handling in debug CLI (ContainerToKeyMapping) `processMultipartUpload` branches on schema version: - legacy MPUs still use embedded PartKeyInfo - split MPUs scan multipartPartsTable by uploadId and map block containers from each part’s locations. Without fix the `ozone debug om container-key-mapping --in-progress` reported no open MPU keys for split-schema uploads, even when their parts used the queried containers, this causes misleading output for debugging container to key mappings on upgraded clusters. ## What is the link to the Apache JIRA https://issues.apache.org/jira/browse/HDDS-15949 ## How was this patch tested? Patch was tested via unit tests -- 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]
