hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hadoop QA (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-6622) Rename and AddBlock may race and produce invalid edits
Date Wed, 09 Jul 2014 17:15:06 GMT

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

Hadoop QA commented on HDFS-6622:

{color:red}-1 overall{color}.  Here are the results of testing the latest attachment 
  against trunk revision .

    {color:green}+1 @author{color}.  The patch does not contain any @author tags.

    {color:green}+1 tests included{color}.  The patch appears to include 1 new or modified
test files.

    {color:red}-1 javac{color:red}.  The patch appears to cause the build to fail.

Console output: https://builds.apache.org/job/PreCommit-HDFS-Build/7305//console

This message is automatically generated.

> 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

View raw message