yandrey321 opened a new pull request, #10741: URL: https://github.com/apache/ozone/pull/10741
## What changes were proposed in this pull request? On OFS, isDirectory(path) and isFile(path) fall through to Hadoop's FileSystem defaults, which call getFileStatus(path).isDirectory(). For a file path this issues a full GetFileStatus OM RPC that, server-side, calls refresh() → refreshPipeline — an extra OM→SCM round-trip to repopulate pipeline/block-location info — and returns the full block-location list. A type check needs none of that. This change makes the OFS type-check path a metadata-only (head-op) request: 1. Client plumbing. A headOp flag is threaded from BasicRootedOzoneFileSystem.isDirectory/isFile down through the adapter, OzoneBucket, ClientProtocol, and RpcClient into the OmKeyArgs used by getFileStatus. Existing callers of getFileStatus keep the full behaviour via overloads/default methods that pass headOp=false. This mirrors the existing RpcClient.getKeyInfo(..., isHeadOp) pattern used by S3 HEAD. 2. OM honours the flag. KeyManagerImpl already skips refresh + sortDatanodes when args.isHeadOp(); the change makes that flag actually arrive: - the client translator (OzoneManagerProtocolClientSideTranslatorPB.getFileStatus) now sets headOp on the request KeyArgs, and - the server handler (OzoneManagerRequestHandler.getOzoneFileStatus) now reads it back into the OmKeyArgs handed to the OM. 3. - Block locations dropped for head ops. Because a head op skips the refresh, its block locations carry no pipeline (and are unused by a type check). The server handler strips keyLocationList from the head-op response proto (on an immutable toBuilder() copy — no OM-cache mutation), keeping the response small. No protobuf change is required — KeyArgs.headOp (field 18) already exists — and the change is wire-compatible: an old server ignores the flag (full behaviour); an old client never sets it. Side notes: The flag was originally dropped by both the client translator and the server handler, so a client-only change was a no-op end-to-end — both sides are now fixed. Skipping the refresh returns block locations with null pipelines; stripping them server-side (item 3) is what prevents a client-side NPE for multi-block files, so it is required, not just an optimization. co-authored with Claude Code ## What is the link to the Apache JIRA https://issues.apache.org/jira/browse/HDDS-15678 ## How was this patch tested? Added unit tests: TestRpcClientGetFileStatusHeadOp — headOp reaches the wire KeyArgs (true/false). TestRootedOzoneFileSystemHeadOp — isDirectory/isFile use head-op; correct results for file/dir/missing paths; error mapping. TestBasicRootedOzoneClientAdapterHeadOp — adapter dispatch + headOp threading (key/root/volume/snapshot, OMException mapping). TestOzoneBucket and TestOzoneManagerRequestHandler — bucket/protocol defaults and the handler forwarding headOp + stripping keyLocationList (retained when not head-op; defensive no-keyInfo path). Integration in AbstractRootedOzoneFileSystemTest#testIsFileAndIsDirectory (runs on TestOFS, TestOFSWithFSO, TestOFSWithFSPaths). No-regression run: unit tests for common, client, ozonefs-common, ozone-manager (clean rebuild — ozone-manager alone 2,530 tests) and the three OFS integration suites (181 tests) — all pass. checkstyle clean on all changed modules. Benchmark (TestOFSIsDirectoryBenchmark, @Tag("benchmark"), not in the normal suite): on a MiniOzoneCluster, isFile (head-op) vs full getFileStatus on a 1-block file — 1.47× throughput (5,078 vs 3,458 ops/s). The gain is understated here (in-process SCM RPC); over a real network the eliminated round-trip costs more. -- 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]
