[
https://issues.apache.org/jira/browse/HDFS-5329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13791608#comment-13791608
]
Brandon Li commented on HDFS-5329:
----------------------------------
The problem we have is that, NFS gateway doesn't know the name of startAfter
and has to use inode id instead.
NFS protocol uses readdir and readdirplus to list directory content. In the
response, each dirent has an 8-byte number verifier.
To list the content of large directories, NFS client sends multiple readdir or
readdirplus requests to NFS gateway with one verifier(resume point) in the
request. The verifier is basically of the same usage as "startAfter" in
getListing. Since NFSv3 uses file handle to communicate and doesn't know the
file name. NFS gateway has to use the inode id path as "startAfter" when
sending getList request to NN, however NN currently expects "startAfter" to be
just a file name. As a result, NFS gateway can't list the content of large
directories.
We have two ways to fix this issue. We can change getListing to be able to get
file name from startAfter's inodeId path as in the second patch. We can also
change getFileInfo to return file name as in the first patch, which seems to
upset lots of unit tests.
> getFileInfo doesn't return file name
> ------------------------------------
>
> Key: HDFS-5329
> URL: https://issues.apache.org/jira/browse/HDFS-5329
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: namenode
> Reporter: Brandon Li
> Assignee: Brandon Li
> Attachments: HDFS-5329.1.patch, HDFS-5329.patch
>
>
> FSDirectory#getFileInfo() always returns empty string as the file name to the
> client.
> When the client is using inode path to get the file info, the client could
> also need the server to return the file name.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
