yandrey321 opened a new pull request, #11674:
URL: https://github.com/apache/ozone/pull/11674
## What changes were proposed in this pull request?
**Problem.** Rooted-ofs `rename` fetches the bucket (`InfoBucket`, plus
`InfoVolume` + `InfoBucket` per link hop)
only to choose the algorithm: FSO sends one `RenameKey`, LEGACY iterates
over the keys, OBJECT_STORE is rejected on
the client. So every FSO rename costs 2 OM requests. OM cannot simply reject
non-FSO buckets in `RenameKey`: the
shell, trash, key lifecycle and `OzoneBucket.renameKey` send it on any
layout, and on LEGACY it renames one key.
**Implementation** (same shape as HDDS-16760 / HDDS-16948):
- `RenameKeyRequest` gets `optional bool requireFileSystemOptimized = 4`.
When it is set,
`OMKeyRenameRequest.preExecute` (inherited by the FSO request) rejects any
bucket whose link-resolved layout is
not FILE_SYSTEM_OPTIMIZED with `NOT_SUPPORTED_OPERATION`, before Ratis. It
tests the layout, not the request class,
because the OBJECT_STORE request class also serves LEGACY. Unlike
`requireFileSystemLayout`, it rejects LEGACY too.
- New `ClientProtocol.renameKey(..., requireFileSystemOptimized)`; the
existing overload is unchanged.
- New `OzoneManagerVersion.RENAME_KEY_REJECTS_NON_FSO(104)`. From that
version on, `BasicRootedOzoneFileSystem.rename`
first sends the flagged `RenameKey` with no `getBucket()`. Success and
`KEY_ALREADY_EXISTS` / `KEY_RENAME_ERROR` /
`KEY_NOT_FOUND` are handled exactly as in today's FSO rename.
`NOT_SUPPORTED_OPERATION`, `BUCKET_NOT_FOUND` and
`VOLUME_NOT_FOUND` fall back to today's path from `getBucket()` on, so
LEGACY renames, OBJECT_STORE rejections and
missing-bucket errors are unchanged. Older OMs, including `ZDU`, keep
today's path.
**Side effects.**
- FSO: 2 -> 1 OM request per rename. LEGACY and OBJECT_STORE: one extra
rejected `RenameKey` before today's path
(the audit log shows a failed `RENAME_KEY` before `INFO_BUCKET`).
- Callers that do not set the field (old clients, shell, trash, lifecycle,
`OzoneBucket.renameKey`) are unaffected.
Generated-by: Claude Code (Claude Opus 5.5)
## What is the link to the Apache JIRA
https://issues.apache.org/jira/browse/HDDS-16951
## How was this patch tested?
**Unit and integration tests**
**Benchmark**
**CPU savings.** CPU profiles of the 10-thread run show the patch saves
about 110 us of CPU per FSO rename: about
67 us on the client (46% of its CPU per rename) and about 44 us on the OM
(about 20% of its request-handling CPU; the
write pipeline is unchanged). Almost all of it is per-RPC overhead, not OM
work: the `InfoBucket` request itself costs
about 2 us. It does not show up as throughput because the benchmark is bound
by the OM's Ratis log fsync, not CPU.
--
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]
