[
https://issues.apache.org/jira/browse/HDFS-6622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14056596#comment-14056596
]
Colin Patrick McCabe commented on HDFS-6622:
--------------------------------------------
bq. I also wanted to reduce the number of times getFullPathName() is called. I
will simply remove the comparison and fix the test to check the correctness of
edit.
OK. From what I can see, the path should be recomputed while under the lock
(rather than simply trusting that it will stay the same since we last released
the lock). That should fix things. It looks like you introduced the FileState
object in order to avoid calling getFullPathName() twice while holding the
lock... fair enough.
+1
> 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
> Assignee: Kihwal Lee
> Priority: Blocker
> Attachments: HDFS-6622.patch, HDFS-6622.v2.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)
