[
https://issues.apache.org/jira/browse/HDFS-6622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kihwal Lee updated HDFS-6622:
-----------------------------
Description:
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.
was:
While investigating HDFS-6681, 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.
> 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
>
> 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)
