yandrey321 opened a new pull request, #11549:
URL: https://github.com/apache/ozone/pull/11549
## What changes were proposed in this pull request?
`ofs` and `o3fs` keep listing until OM returns a page that adds nothing. So
every `listStatus`, even of a directory
that fits in one page, costs at least two ListStatus RPCs; the second one
only returns the repeated start key.
The client cannot stop on a short page on its own. OM caps the page size
with server settings the client doesn't
know (`ozone.om.server.list.max.size`, `ozone.fs.listing.page.size.max`),
and a client-side rule would cut off large
directories. That is why HDDS-11696 removed it.
This PR lets OM say whether the listing may continue, as `ListKeysResponse`
already does.
Key decisions:
- **OM decides, against the limit it actually applied.** `isTruncated =
returned >= effective page size`, where the
effective page size is the request capped by both server limits and raised
to the minimum of 2. It is not compared
with the requested size. The rule lives in one helper,
`OmMetadataReader.listStatusPageSize`, now used by both
`listStatus` and `listStatusLight` and by the request handler, so the flag
can't drift from what the listing used.
- **A short page means the listing is complete, on both listing paths.**
Both return `min(effective page size,
remaining live entries)`:
- FSO: cache tombstones and DB keys shadowed by the cache never reach the
heap.
- LEGACY/OBS: only newly added live entries count toward the limit.
When exactly a full page remains, the flag is `true` and the client makes
one more call, as it does today.
A look-ahead could save that call but isn't needed for correctness.
- **No version gate.** The flag is an `optional` field. If an older OM
doesn't set it, the client treats it as
unknown and keeps the current loop. Older clients ignore it.
Implementation details:
- **Proto:** `optional bool isTruncated` in `ListStatusResponse` and
`ListStatusLightResponse`. No request field,
result code or configuration change.
- **Client plumbing:** new `ListStatusResult<T>` holds the entries and
whether OM reported the listing complete
(`of` / `unknown` / `map`).
- Page methods are added as `default` methods on `OzoneManagerProtocol`,
`ClientProtocol` and
`OzoneClientAdapter`. The defaults report "unknown", so other
implementations and test stubs are unaffected.
- The real implementations override them: the translator, `RpcClient`,
both file-system adapters, and
`OzoneBucket`.
- The existing `List`-returning methods stay and delegate to the page
methods.
- **`ofs`:** root, volume and snapshot listings don't come from ListStatus
and stay "unknown". The listing path for
OMs older than `LIST_STATUS_REJECTS_OBS` is unchanged, since those OMs
never set the flag.
- **File system loops:** `listStatus` and `listStatusIterator` in both `ofs`
and `o3fs` stop after a page OM reports
complete: `while (entriesAdded > 0 && !page.isComplete())`. The iterators
skip the extra fetch the same way.
Generated-by: Claude Code (claude-opus-5-5)
## What is the link to the Apache JIRA
https://issues.apache.org/jira/browse/HDDS-16943
## How was this patch tested?
Unit + Integration tests
**Benchmark:** `TestOfsListStatusRpcBenchmark`
- Workload: 2,000 `ofs` `listStatus` calls on directories of 10 entries,
single-threaded and with 10 threads.
- Baseline: `3c2a71d9d9`, which already includes HDDS-16760.
- 3 runs per arm, the arms run one after the other. Medians, with the range
over runs:
| | Baseline | This PR | Change |
|---|---|---|---|
| OM RPCs per `listStatus` | 2.00 | 1.00 (exact, every run) | −50% |
| 1 thread: mean / p50 latency | 0.605 / 0.584 ms | 0.319 / 0.308 ms | −47%
/ −47% |
| 1 thread: p99 latency | 0.776 ms (0.755–0.804) | 0.424 ms (0.409–0.429) |
−45% |
| 1 thread: throughput | 1,652/s | 3,129/s | +89% |
| 10 threads: mean / p50 latency | 1.168 / 1.063 ms | 0.607 / 0.534 ms |
−48% / −50% |
| 10 threads: throughput | 8,486/s (8,087–8,671) | 16,324/s (14,751–16,498)
| +92% |
Analysis:
- The latency roughly halves because the removed RPC costs about as much as
the first one. It is a full OM
round trip that returns only the start key. Throughput nearly doubles for
the same reason.
- 10-thread p99 is not quoted: it varied 2.0–7.9 ms on the baseline and
1.0–5.6 ms with the fix.
- Combined with HDDS-16760, an `ofs` `listStatus` of a one-page directory
went from 4 OM RPCs to 1.
- The benchmark runs on a mini-cluster over loopback. On a real cluster, the
saved round trip is worth more in
absolute terms.
--
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]
