matanper opened a new issue, #68790: URL: https://github.com/apache/doris/issues/68790
### Search before asking - [x] I had searched in the [issues](https://github.com/apache/doris/issues?q=is%3Aissue) and found no similar issues. ### Version 4.1.4 (storage-compute separated / cloud mode). Also present on `master` at cfb47188bf (2026-10-08). ### What's Wrong? Creating a storage vault with the `path_version` or `shard_num` property always fails: ```sql CREATE STORAGE VAULT s3_vault_v1 PROPERTIES ( "type" = "S3", "s3.endpoint" = "s3.us-east-1.amazonaws.com", "s3.region" = "us-east-1", "s3.bucket" = "<bucket>", "s3.root.path" = "<prefix>", "provider" = "S3", "path_version" = "1", "shard_num" = "1024" ); ``` ``` ERROR ... java.lang.UnsupportedOperationException ``` Cause, in `fe/fe-core/src/main/java/org/apache/doris/nereids/trees/plans/commands/CreateStorageVaultCommand.java`: - The constructor stores the properties as a Guava `ImmutableMap`: `this.properties = ImmutableMap.copyOf(properties);` (line 64). - `validate`/`analyze` then reads the two properties and calls `properties.remove(PATH_VERSION)` (line 117) and `properties.remove(SHARD_NUM)` (line 122). - `ImmutableMap.remove` always throws `UnsupportedOperationException`. So under the Nereids planner, `path_version` / `shard_num` cannot be set on a new vault at all. The hashed object-key layout is therefore unreachable, even though the BE and the meta-service/recycler already support it. ### What You Expected? The vault is created with the requested `path_version` and `shard_num`, and both are passed to the meta-service, so new tablets use the sharded object-key layout. ### How to Reproduce? On a cloud-mode cluster, run the `CREATE STORAGE VAULT` statement above with `"path_version" = "1"` (and/or `"shard_num"`). It fails immediately with `UnsupportedOperationException`. Without those two properties it succeeds. ### Anything Else? Why it matters: with `path_version=0` the keys are `data/<tablet_id>/...`. Tablet ids are allocated sequentially, so after a TRUNCATE or table re-create all new writes land in one narrow key range. Under heavy ingest (about 23 Gbit/s of S3 uploads per BE) we hit tens of thousands of `SlowDown`/503 responses on `UploadPart`, and loads failed. The sharded layout is the intended way to avoid this. Suggested fix: copy the properties into a mutable map before removing the two keys (e.g. `Map<String, String> props = new HashMap<>(properties);`), then rebuild the `ImmutableMap` from `props`. The same pattern is worth checking in the ALTER STORAGE VAULT path and the vault-creation helpers. ### Are you willing to submit PR? - [x] Yes I am willing to submit a PR! ### Code of Conduct - [x] I agree to follow this project's [Code of Conduct](https://www.apache.org/foundation/policies/conduct) -- 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]
