[
https://issues.apache.org/jira/browse/HDFS-4258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13572819#comment-13572819
]
Brandon Li commented on HDFS-4258:
----------------------------------
Maybe the sub-JIRA number makes it look a bigger code modification than it
actually is. :-)
The esential change here is to add inode id as an additional sanity check for
file modification.
Since it adds one more field in INode, it has to involve a few things like
persistence and RPC changes. The idea and implementation is still very
strait-forward.
A few of the sub-JIRAs are low priority incremental changes, such as
HDFS-4454(enable offline-viewer to show the id) and HDFS-4398(Change WebHDFS to
support file ID).
HDFS-4434(Provide a mapping from INodeId to INode) is not closed only because I
want to use it to discuss the possibility/beneifit of having such a
functionality.
For HDFS-4466(include fileid in other related RPC calls), if you think it's not
neceissary a sub-JIRA, I can move it out. Nevertheless, I will update its
description with more details.
If you still think we should do the rest of the work in a branch, I am OK with
it too.
> 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
