[jira] [Commented] (HDFS-6622) Rename and AddBlock may race and produce invalid edits

[Colin Patrick McCabe (JIRA)]

    [ 
https://issues.apache.org/jira/browse/HDFS-6622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14050843#comment-14050843
 ] 

Colin Patrick McCabe commented on HDFS-6622:
--------------------------------------------

I think the best solution is to recompute the path once we take the lock the 
second time.  If we take the path directly from the inode, we know that it will 
be correct.

{code}
diff --git 
a/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/FSNamesystem.java
 
b/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/FSNamesystem.java
index cc522e4..808734a 100644
--- 
a/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/FSNamesystem.java
+++ 
b/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/FSNamesystem.java
@@ -2805,6 +2805,7 @@ LocatedBlock getAdditionalBlock(String src, long fileId, 
String clientName,
       LocatedBlock[] onRetryBlock = new LocatedBlock[1];
       final INodeFile pendingFile =
           analyzeFileState(src, fileId, clientName, previous, onRetryBlock);
+      src = pendingFile.getFullPathName();
 
       if (onRetryBlock[0] != null) {
         if (onRetryBlock[0].getLocations().length > 0) {
{code}

> Rename and AddBlock may race and produce invalid edits
> ------------------------------------------------------
>
>                 Key: HDFS-6622
>                 URL: https://issues.apache.org/jira/browse/HDFS-6622
>             Project: Hadoop HDFS
>          Issue Type: Bug
>    Affects Versions: 2.5.0
>            Reporter: Kihwal Lee
>            Priority: Blocker
>         Attachments: HDFS-6622.patch
>
>
> While investigating HDFS-6618, we have discovered that rename happening in 
> the middle of {{getAdditionalBlock()}} can lead to logging of invalid edit 
> entry.
> In  {{getAdditionalBlock()}} , the path is resolved once while holding the 
> read lock and the same resolved path will be used in the edit log in the 
> second half of the method holding the write lock.  If a rename happens in 
> between two locks, the path may no longer exist. 
> When replaying the {{AddBlockOp}}, it will fail with FileNotFound.



--
This message was sent by Atlassian JIRA
(v6.2#6252)