hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aaron T. Myers (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-4258) Rename of Being Written Files
Date Wed, 06 Feb 2013 22:32:13 GMT

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

Aaron T. Myers commented on HDFS-4258:
--------------------------------------

bq. Where?

In [this comment|https://issues.apache.org/jira/browse/HDFS-4258?focusedCommentId=13537283&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13537283]
where Brandon says the following:

bq. add new addBlock interface which takes the id as an additional field. The id is checked
by checkLease(). *If it doesn't match current id in the found inode, NN fails the request.*

bq. Is the concern you are expressing that InodeID introduction is not a part of this jira?

The concern that I have is that introducing INode IDs doesn't seem like it's strictly required
to address the bug described by this JIRA, and seems like a much heavier-weight solution than
possible alternatives, for example something like what Todd proposed.

As I said previously, I can imagine several motivations for wanting unique INode IDs, but
I don't think the bug described by this JIRA is necessarily one of them.
                
> Rename of Being Written Files
> -----------------------------
>
>                 Key: HDFS-4258
>                 URL: https://issues.apache.org/jira/browse/HDFS-4258
>             Project: Hadoop HDFS
>          Issue Type: Bug
>          Components: hdfs-client, namenode
>    Affects Versions: 3.0.0
>            Reporter: Tsz Wo (Nicholas), SZE
>            Assignee: Brandon Li
>         Attachments: HDFS-4258.patch, HDFS-4258.patch, HDFS-4258.patch, HDFS-4258.patch
>
>
> When a being written file or it's ancestor directories is renamed, the path in the file
lease is also renamed.  Then the writer of the file usually will fail since the file path
in the writer is not updated.
> Moreover, I think there is a bug as follow:
> # Client writes 0's to F_0="/foo/file" and writes 1's to F_1="/bar/file" at the same
time.
> # Rename /bar to /baz
> # Rename /foo to /bar
> Then, writing to F_0 will fail since /foo/file does not exist anymore but writing to
F_1 may succeed since /bar/file exits as a different file.  In such case, the content of /bar/file
could be partly 0's and partly 1's.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message