[
https://issues.apache.org/jira/browse/HDFS-5329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13793063#comment-13793063
]
Brandon Li commented on HDFS-5329:
----------------------------------
NFS server returns the directory modification time to NFS clients.
If the client noticed the directory is changed(e,g., the startAfter file is
deleted, or other files are added), NFS client implements would redo the
directory listing from the beginning, or accept whatever returned by the
server. Given NFS gateway always returns directory mtime along with the listing
result, it's acceptable that HDFS lists the directory form the beginning if the
startAfter file can't be found.
> Update FSNamesystem#getListing() to handle inode path in startAfter token
> -------------------------------------------------------------------------
>
> 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.2.patch, HDFS-5329.3.patch,
> HDFS-5329.patch
>
>
> This is to support network protocols which can't use file name as the token
> to resume directory listing.
> 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.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
