[
https://issues.apache.org/jira/browse/HDFS-17164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17757099#comment-17757099
]
ASF GitHub Bot commented on HDFS-17164:
---------------------------------------
szetszwo commented on code in PR #5974:
URL: https://github.com/apache/hadoop/pull/5974#discussion_r1300668156
##########
hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/datanode/LocalReplica.java:
##########
@@ -367,12 +367,23 @@ public void setPinning(LocalFileSystem localFS) throws
IOException {
}
@Override
- public void bumpReplicaGS(long newGS) throws IOException {
+ public void bumpReplicaGS(long newGS, String trashDir) throws IOException {
long oldGS = getGenerationStamp();
final File oldmeta = getMetaFile();
setGenerationStamp(newGS);
final File newmeta = getMetaFile();
+ if (trashDir != null) {
Review Comment:
@umamaheswararao , thanks a lot for reviewing this! You are right. It
should not copy again if the block already exists in trash. Updated the code.
> During rolling upgrade, datanode should copy-on-append when bumpReplicaGS
> -------------------------------------------------------------------------
>
> Key: HDFS-17164
> URL: https://issues.apache.org/jira/browse/HDFS-17164
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: datanode, rolling upgrades
> Reporter: Tsz-wo Sze
> Assignee: Tsz-wo Sze
> Priority: Major
> Labels: pull-request-available
>
> During rolling upgrade, datanode create a trash directory for each block
> pool. Then a block deletion becomes moving the block to trash.
> For bumpReplicaGS, it will rename the meta file and then continue writing to
> the block file. It should copy the original block file and the original meta
> file to trash in order to support rollback.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
