devmadhuu commented on code in PR #11399:
URL: https://github.com/apache/ozone/pull/11399#discussion_r4402631229
##########
hadoop-hdds/server-scm/src/main/java/org/apache/hadoop/hdds/scm/container/ContainerReplica.java:
##########
@@ -150,6 +150,19 @@ public StorageType getVolumeStorageType() {
return volumeStorageType;
}
+ /**
+ * The storage type a copy of this replica should be placed on to stay on the
+ * same tier. Prefers the volume the replica actually lives on, since that is
+ * ground truth, and falls back to the type the container was created for.
+ *
+ * @return the storage type to target, or null when neither was reported,
which
+ * leaves the target free to choose any volume
+ */
+ @Nullable
+ public StorageType getTargetStorageTypeForCopy() {
+ return volumeStorageType != null ? volumeStorageType : storageType;
+ }
Review Comment:
Good point. Yes, the current implementation prefers volumeStorageType
because usage statistics are grouped by the volume’s currently reported type.
However, your relabel example exposes a limitation. Relabelling does not change
the underlying hardware. Copying this replica to a genuine DISK volume would
preserve the reported label, but could change the actual storage medium from
SSD to HDD. Therefore, aligning with usage statistics alone does not fully
justify the preference.
So I was thinking : Would it be safer to exclude replicas when both fields
are present and mis-match and avoid balancing. We can report in container
balancer report why such few containers were excluded from getting them
balanced. As of today also, we have many conditions in container balancer which
makes some containers being excluded.
--
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]
