devmadhuu commented on code in PR #11926:
URL: https://github.com/apache/ozone/pull/11926#discussion_r4467353092
##########
hadoop-hdds/container-service/src/main/java/org/apache/hadoop/ozone/container/replication/ContainerImporter.java:
##########
@@ -121,6 +125,10 @@ public void importContainer(long containerID, Path
tarFilePath,
}
ContainerUtils.verifyContainerFileChecksum(containerData, conf);
containerData.setVolume(targetVolume);
+ // The descriptor carries the source volume's storage type. Record the
Review Comment:
Thanks @anuragp010 for review, I agree that a known replica storageType
should not be replaced simply because its volume has been relabelled. Using
volumeStorageType as a fallback is needed for legacy replicas whose stored
storageType is null, as discussed in #11866
(https://github.com/apache/ozone/pull/11866#issuecomment-6623770266).
The copy flow needs to agree on the type before storing the new replica:
1. SCM determines the required destination type.
2. SCM uses that type when selecting a target datanode and includes it in
the replication command.
3. The source datanode forwards it in the upload request.
4. The destination selects a matching volume and imports the replica.
5. The imported metadata records the type resolved for that copy.
For example, if the source replica records SSD, a same-type copy should
select an SSD target and send an SSD request. If an old replica has storageType
= null but reports volumeStorageType = SSD, that report can supply the missing
type.
If the replica records SSD but its volume reports DISK after relabelling,
that disagreement needs separate handling, so yes we should not silently
reinterpret the replica as DISK. The earlier proposal on #11399
(https://github.com/apache/ozone/pull/11399#discussion_r4402631229) was to
exclude such replicas from balancing and report the reason.
At the importer line being reviewed, targetVolume has already been selected.
Simply preserving SSD in the metadata would not fix a copy that has already
selected a DISK volume. Conversely, the current unconditional assignment from
the destination volume can overwrite a known source type. This needs attention
in this PR, #11926, including the case where the copy request supplies no type.
The importer should not hide a disagreement by changing the recorded type.
So in this PR, I am fixing by checking if legacy or container has no storage
type metadata, then selecting target volume. Remaining work will be in follow
up PR, where we resolve the source replica’s type, handle unknown or
conflicting reports, select a matching target, and pass the same type to the
copy command.
--
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]
