[ 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