[
https://issues.apache.org/jira/browse/HDFS-6622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14056449#comment-14056449
]
Kihwal Lee commented on HDFS-6622:
----------------------------------
The reason I added the strict check was to prevent incorrect operations based
on potentially incorrect result from getFullPathName(). If the inode's parent
is not null (stale), but one of the ancestor's parent is null, it will assume
that inode is directly under "/". This could happen with the delayed inode
removal. But since we are going to remove inodes from inodeMap while holding
FSNamesystem write lock, this should not happen. So what you suggest will be
sufficient.
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.
> 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, 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)
