hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jing Zhao (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-7104) Fix and clarify INodeInPath getter functions
Date Tue, 23 Sep 2014 22:45:34 GMT

    [ 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
> 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

View raw message