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

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

bq. Sorry I misunderstood the previous comment you had posted. 

No problem. :)

bq. So you are okay using INodeID in checkLease() to solve this bug.

Regarding this particular JIRA, given Todd's last comment, I'm not convinced 
that this is in fact currently a bug, since it seems like the current code may 
already handle this case properly. Let's investigate that separately from 
introducing INode IDs, perhaps by just writing up a little test case that 
exposes the bug.

bq. If I understand it correctly, I agree with moving some of the subtasks to 
another umbrella jira that goes some thing like "Use InodeID as as an 
identifier of a file in HDFS protocols and APIs" and move some of the subtasks 
of this jira under that. We could also add description of what needs to be done 
and motivations.

That sounds great, and I think that all of the INode ID work should be done on 
a branch off of trunk so that it can reasonably be done incrementally. 
Description of the design and motivations for the change would go into the new 
umbrella JIRA you propose.

Thanks a lot for your understanding, Suresh.
                
> 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

Reply via email to