yandrey321 opened a new pull request, #11226:
URL: https://github.com/apache/ozone/pull/11226
## What changes were proposed in this pull request?
OFS `getFileStatus` on a non-snapshot path used to issue **two** OM RPCs per
call:
an `InfoBucket` RPC (only so the client could read the bucket layout and
reject
OBJECT_STORE buckets, which have no file system semantics) followed by the
actual
`getFileStatus` RPC. On a namespace-walk / listing-heavy workload this
doubles the
OM read-RPC volume for no functional gain.
This PR removes the redundant `InfoBucket` RPC by moving the layout check to
where
the authoritative bucket metadata already lives — the OM:
* **Client (`BasicRootedOzoneClientAdapterImpl`)** — the non-snapshot
`getFileStatus`
path now calls `proxy.getOzoneFileStatus(...)` directly instead of first
fetching
the bucket. Mutating OFS operations still resolve and validate layout
through
`getBucket(...)`, and snapshot paths are unchanged.
* **Server (`OmMetadataReader.getFileStatus`)** — validates the bucket
layout and
rejects OBJECT_STORE buckets. The `IllegalArgumentException` from
`OzoneFSUtils.validateBucketLayout` is wrapped as
`OMException(NOT_SUPPORTED_OPERATION)` so it is returned as a normal
(non-retryable) RPC response instead of escaping the read handler's
`IOException`
catch and triggering a client-side retry storm.
* **Client error mapping** — on `NOT_SUPPORTED_OPERATION` the adapter
re-throws
`IllegalArgumentException` (preserving the pre-existing OFS behavior and
message),
keyed on the `ResultCode` rather than on the message text so the two sides
are not
coupled through a string.
No protobuf/wire change: RPC signatures and the `GetFileStatus` messages are
unchanged, and `NOT_SUPPORTED_OPERATION` is a pre-existing result code.
### Compatibility note
The OBS-rejection check moves from the client to the OM. In a rolling
upgrade, a
**new OFS client talking to an old OM** will no longer reject
`getFileStatus` on an
OBJECT_STORE bucket, because the old OM has no server-side check and the new
client
no longer performs the `InfoBucket`-based one. New-client/new-OM and
old-client/*
are unaffected. Flagging for reviewer sign-off on whether that upgrade
window needs
a version gate or a retained client-side fallback.
Generated-by: Claude Code (Claude Opus 4.8)
## What is the link to the Apache JIRA
https://issues.apache.org/jira/browse/HDDS-15925
## How was this patch tested?
* Unit: `TestOMMetadataReader` (server-side rejection returns
`OMException(NOT_SUPPORTED_OPERATION)`, `keyManager.getFileStatus` not
called for
OBS), `TestBasicRootedOzoneClientAdapterHeadOp` (8/8).
* Integration: `TestOFS#testGetFileStatusRejectsObsBucket` — verifies OBS
`getFileStatus` is rejected over RPC as `IllegalArgumentException` with
**0**
InfoBucket RPCs; the OFS getFileStatus suite in
`AbstractRootedOzoneFileSystemTest`.
* Benchmark: `TestOfsGetFileStatusCacheBenchmark` (tagged `benchmark`),
numbers above.
* `checkstyle.sh` clean; affected modules build.
### Benchmark
Measured with `TestOfsGetFileStatusCacheBenchmark` (200 buckets × 10
accesses =
2000 getFileStatus calls), same base and machine, against baseline and the
client-side cache alternative (PR #11176):
| Metric | Baseline | #11176 (client cache) | This PR (server-side) |
|---|---|---|---|
| InfoBucket RPCs | 2000 | 200 | **0** |
| getFileStatus RPCs | 2000 | 2000 | 2000 |
| Single-thread p99 | 0.32–0.48 ms | 0.29–0.37 ms | 0.22–0.28 ms |
| Single-thread throughput | ~3.7–4.5k ops/s | ~5.4–6.5k ops/s | ~6.1–7.2k
ops/s |
| 10-thread p99 | 1.033 ms | 0.818 ms | 0.719 ms |
| 10-thread throughput | 16.2k ops/s | 26.9k ops/s | 26.1k ops/s |
The `getFileStatus` RPC count is identical everywhere — the change removes
only the
redundant `InfoBucket` RPC. This PR removes it entirely (0), giving the
lowest RPC
count and the best latency tail with no client-side cache state or new
config.
--
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]
