[
https://issues.apache.org/jira/browse/HDFS-7104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14145567#comment-14145567
]
Jing Zhao commented on HDFS-7104:
---------------------------------
Thanks for the analysis, [~zhz].
For all the callers of {{getINodes}}, we have the following two cases:
# The path is a non-snapshot path. In this case the {{getINodes}} returns
inodes directly, which includes null elements.
# The path is a snapshot path (including paths ending with dot-snapshot). In
this case, the current {{getINodes}} trims elements to make the length of
{{inodes}} equal to the value of {{capacity}}. Note that in this case null
elements may still be contained in {{inodes}} (otherwise we cannot identify
non-existing files/directories in snapshots).
So I can see three options here. The first option is to keep the current
{{getINodes}} unchanged, but adding more javadoc to explain the logic behind.
The second option is to make it a real getter, but we cannot rename it to
{{getNonNullINodes}} since null elements can still be included.
The third option is to also create an extra method
{{INodesInPath#getINodesForWrite}} for the above case #1, which first does a
sanity check to make sure {{capacity == inodes.length}}, and then returns
{{inodes}} directly. This method can be called by write ops like mkdir, concat,
delete, etc.
Since we do not usually call {{getINodes}} multiple times for the same
INodesInPath instance, I think we may consider starting from option 2.
> Fix and clarify INodeInPath getter functions
> --------------------------------------------
>
> Key: HDFS-7104
> URL: https://issues.apache.org/jira/browse/HDFS-7104
> Project: Hadoop HDFS
> Issue Type: Bug
> Reporter: Zhe Zhang
> Assignee: Zhe Zhang
> Priority: Minor
> Attachments: HDFS-7104-20140923-v1.patch, HDFS-7104-20140923-v2.patch
>
>
> inodes is initialized with the number of patch components. After resolve, it
> contains both non-null and null elements (introduced by dot-snapshot dirs).
> When getINodes is called, an array is returned excluding all non elements,
> which is the correct behavior. Meanwhile, the inodes array is trimmed too,
> which shouldn't be done by a getter.
> Because of the above, the behavior of getINodesInPath depends on whether
> getINodes has been called, which is not correct.
> The name of getLastINodeInPath is confusing – it actually returns the last
> non-null inode in the path. Also, shouldn't the return type be a single INode?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
