fapifta opened a new pull request, #6988: URL: https://github.com/apache/ozone/pull/6988
## What changes were proposed in this pull request? In the BasicRootedOzoneClientAdapterImpl#getFileStatus call within the getFileStatusForKeyOrSnapshot method, in most of the cases we do not need just the name of the bucket to get to OM and ask for the file status. In those cases we should not get the bucketInfo first in a separate RPC, and then get the bucket object to call the client protocol for the file status in an other RPC as we do now. ## What is the link to the Apache JIRA https://issues.apache.org/jira/browse/HDDS-11232 ## How was this patch tested? I have created a special client that logs RPC calls that it makes, and ran some FS API call tests with a client that emits some additional logs, before and after this change. Logging in this client was added to the OzoneManagerProtocolClientSideTranslatorPB@submitRequest call, and nothing else was changed to get the logging. (It is just basically simpler than to collect information from the client side TRACE logs from hadoop ipc.) Output before the change: Before: Submitting RPC request: ServiceList Creating base directory /pifta/test/dir in Ozone (api call: fs.mkdirs) Submitting RPC request: InfoBucket Submitting RPC request: CreateDirectory Copy from local to /pifta/test/dir/copyFromLocal (api call: fs.copyFromLocalFile) Submitting RPC request: InfoBucket Submitting RPC request: GetFileStatus Submitting RPC request: InfoBucket Submitting RPC request: CreateFile Submitting RPC request: CommitKey Cross bucket copy from /pifta/test/dir/copyFromLocal to /test/test/foo (api call: FileUtil.copy) Submitting RPC request: InfoBucket Submitting RPC request: GetFileStatus Submitting RPC request: InfoBucket Submitting RPC request: GetFileStatus Submitting RPC request: InfoBucket Submitting RPC request: GetKeyInfo Submitting RPC request: InfoBucket Submitting RPC request: CreateFile Submitting RPC request: CommitKey Cleanup /test/test/foo (api call: fs.delete - on file) Submitting RPC request: InfoBucket Submitting RPC request: GetFileStatus Submitting RPC request: InfoBucket Submitting RPC request: DeleteKey Submitting RPC request: InfoBucket Submitting RPC request: GetFileStatus Cleanup /pifta/test/dir (api call: fs.delete - on directory recursively) Submitting RPC request: InfoBucket Submitting RPC request: GetFileStatus Submitting RPC request: InfoBucket Submitting RPC request: InfoBucket Submitting RPC request: DeleteKey After the change the same code generates the following output: Submitting RPC request: ServiceList Creating base directory /pifta/test/dir in Ozone (api call: fs.mkdirs) Submitting RPC request: InfoBucket Submitting RPC request: CreateDirectory Copy from local to /pifta/test/dir/copyFromLocal (api call: fs.copyFromLocalFile) Submitting RPC request: GetFileStatus Submitting RPC request: InfoBucket Submitting RPC request: CreateFile Submitting RPC request: CommitKey Cross bucket copy from /pifta/test/dir/copyFromLocal to /test/test/foo (api call: FileUtil.copy) Submitting RPC request: GetFileStatus Submitting RPC request: GetFileStatus Submitting RPC request: InfoBucket Submitting RPC request: GetKeyInfo Submitting RPC request: InfoBucket Submitting RPC request: CreateFile Submitting RPC request: CommitKey Cleanup /test/test/foo (api call: fs.delete - on file) Submitting RPC request: GetFileStatus Submitting RPC request: InfoBucket Submitting RPC request: DeleteKey Submitting RPC request: GetFileStatus Cleanup /pifta/test/dir (api call: fs.delete - on directory recursively) Submitting RPC request: GetFileStatus Submitting RPC request: InfoBucket Submitting RPC request: InfoBucket Submitting RPC request: DeleteKey AS you can see copyFromLocalFile use 1 less InfoBucket RPC calls, copy uses 2 less InfoBucket calls, and non recursive delete of a file uses 2 less while recursive delete of a dir with one file uses 1 less InfoBucket RPC calls. Other than this the current tests should cover for the change. -- 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]
