yandrey321 opened a new pull request, #11613:
URL: https://github.com/apache/ozone/pull/11613
## What changes were proposed in this pull request?
**Problem.** Rooted-ofs `open` sends an `InfoBucket` (plus `InfoVolume` +
`InfoBucket` per link hop) only to reject
OBJECT_STORE buckets on the client, then sends `GetKeyInfo`: at least 2 OM
requests per `open`. OM cannot simply
reject OBJECT_STORE in `GetKeyInfo`, because the RPC also serves object
store reads (`readKey`, `getKeyDetails`,
S3 GetObject/HeadObject).
**Implementation** (same shape as HDDS-16760):
- `GetKeyInfoRequest` gets `optional bool requireFileSystemLayout = 3`. When
it is set, `OmMetadataReader.getKeyInfo`
rejects an OBJECT_STORE bucket (link-resolved) with
`NOT_SUPPORTED_OPERATION`, before the ACL check.
- New `ClientProtocol.readFile(volume, bucket, key,
requireFileSystemLayout)`; `RpcClient` also sets the field on the
read-retry `GetKeyInfo`. `OzoneBucket.readFile` is unchanged.
- New `OzoneManagerVersion.GET_KEY_INFO_REJECTS_OBS(102)`. From that version
on, the adapter skips `getBucket()` and
maps the rejection to the same `IllegalArgumentException` and message as
before. Older OMs, including `ZDU`, keep
the current path.
**Side effects.**
- A missing bucket now fails in `GetKeyInfo` instead of `InfoBucket`: same
`BUCKET_NOT_FOUND`, different audit entry.
## What is the link to the Apache JIRA
https://issues.apache.org/jira/browse/HDDS-16948
## How was this patch tested?
**Unit and integration tests**
| | baseline | patch | change |
|---|---|---|---|
| OM RPCs per `open` | 2.00 | 1.00 | exact, every run |
| 1 thread, mean latency | 0.310 ms | 0.221 ms | -29% |
| 1 thread, throughput | 3227/s | 4530/s | +40% |
| 10 threads, p50 latency | 0.687 ms | 0.415 ms | -40% |
| 10 threads, throughput | 13707/s | 21237/s | ~+55% |
**Analysis.** The RPC count halves exactly in every run. Single-thread
latency falls by about 30%, not by half: the
remaining `GetKeyInfo` and the client-side work of `open` stay (the
benchmark does not time them separately).
The 10-thread gain is larger, since the OM serves half as many requests
under contention. One of the three patch runs
was slower at 10 threads (17298/s), so the concurrent figures are
approximate. Loopback RPC on one machine has no network round trip, so on a
real cluster each saved RPC is expected to save more time; that was not
measured here.
--
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]
