devmadhuu commented on code in PR #11229:
URL: https://github.com/apache/ozone/pull/11229#discussion_r4270140082
##########
hadoop-ozone/s3gateway/src/main/java/org/apache/hadoop/ozone/s3/util/S3Consts.java:
##########
@@ -131,6 +131,11 @@ public final class S3Consts {
/** Request header carrying the list of object attributes to return. */
public static final String OBJECT_ATTRIBUTES_HEADER =
"x-amz-object-attributes";
+ // S3 storage class values passed via the `x-amz-storage-class` request
header.
+ public static final String S3_STORAGE_CLASS_STANDARD = "STANDARD";
+ public static final String S3_STORAGE_CLASS_STANDARD_IA = "STANDARD_IA";
+ public static final String S3_STORAGE_CLASS_GLACIER = "GLACIER";
+
Review Comment:
@Gargi-jais11 Agree that fields should be optional. On your question "`Where
does the reverse direction get the policy?`", this patch #11377 keys can
override the bucket default.
The reverse direction reads `KeyInfo.storagePolicy` and never fills a
missing value from the bucket. So `SetBucketProperty` to `COLD` won't relabel
existing objects as `GLACIER`. `KeyInfo.storagePolicy `is only set when a
policy was explicitly requested on the write, so a key that inherited its
policy has null, and null falls back to the replication-based mapping.
@SaketaChalamchala :
**Here is my proposal:**
Since forward mapping already reads `x-amz-meta-storage-config` and only
falls back to 3-2 without it, and reverse mapping already maps any EC layout to
`STANDARD_IA`. The change keeps that and adds the bucket's EC default as a
fallback.
```
S3 storage class Ozone replication
Ozone storage policy
STANDARD RATIS/THREE
Configurable; unset by default
REDUCED_REDUNDANCY RATIS/ONE
Configurable; unset by default
STANDARD_IA EC (resolved using the existing layout
configuration) WARM
GLACIER RATIS/THREE
COLD
```
On whether `STANDARD` should map to HOT: explicit settings already override
the bucket at below paths:
1. Normal keys resolve storage policy as key → bucket → cluster default, so
ozone sh key put --storagepolicy HOT into a COLD bucket lands on SSD.
2. S3 headers already override the bucket's replication. In a bucket whose
default replication is EC, a PUT with no header inherits EC, but a PUT with
STANDARD writes RATIS/THREE, because
S3Utils.resolveS3ClientSideReplicationConfig uses the header first and only
falls back to the bucket when there's none.
So mapping `STANDARD` to `HOT` would be consistent. But it changes what new
writes do, in four ways:
1. More data on `SSD`. Today a `STANDARD` write goes wherever the bucket
policy or the cluster default (`WARM`, so `DISK`) puts it. With `HOT`, every
`STANDARD` write goes to `SSD` first, which can fill an `SSD` tier sized only
for a few `HOT` buckets.
2. Writes can fail that succeed today. `HOT` falls back to `DISK` only if
the bucket allows fallback. Unset defaults to allowed, but in a bucket where an
admin set `allowFallbackStoragePolicy=false` (Already a flag in storage policy
design), a `STANDARD` write fails when `SSD` is full.
3. Placement varies during a rolling upgrade. Old S3 Gateways send no
policy, old OMs ignore `KeyArgs.storagePolicy`, and old datanodes ignore the
storage type. Until the upgrade finishes, the same STANDARD PUT can land on SSD
or DISK depending on which nodes handle it. Nothing is lost or mislabelled, but
placement isn't reliable.
4. An explicit `STANDARD` overrides the bucket policy, as @Gargi-jais11
raised.
So I'd like to make the storage policy for `STANDARD` and
`REDUCED_REDUNDANCY` a gateway setting that defaults to unset. With the
default, nothing changes for existing clusters: these classes inherit the
bucket policy, which avoids points 1, 2 and 4. Admins who want `STANDARD` on
`SSD` can set it to `HOT` once their upgrade is finalized and their SSD tier is
sized for it, which avoids point 3. This also leaves room for the admin-defined
classes @xichen01 mentioned.
I'd make the reverse direction a rule rather than an exact lookup:
replication decides the class, and only COLD changes it.
-- COLD + RATIS -> GLACIER
-- COLD + EC -> GLACIER_DEEP (if we add it)
-- anything else -> replication-based mapping, as today
With this reverse rule, changing `STANDARD`'s policy to `HOT`, whether by
default or through the setting, doesn't relabel existing objects. Old ones
(`RATIS/THREE, null`) and new ones (`RATIS/THREE, HOT`) both report `STANDARD`,
so no migration of existing keys is needed. This depends on the reverse rule
staying lenient. A stricter reverse mapping later would need existing keys
migrated first.
@SaketaChalamchala on your question: `"can a key with no header inherit `EC`
replication and `HOT` policy from the bucket?"`
So a bucket with `EC` and `HOT` stores `EC` data on `SSD`. The key's stored
policy is null, though, because it was inherited rather than requested, so on
reads it reports STANDARD_IA from its replication. The `EC + HOT `reverse case
only arises when a write explicitly requests `HOT` on an `EC` key.
--
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]
