hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brandon Li (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-5329) getFileInfo doesn't return file name
Date Thu, 10 Oct 2013 15:55:42 GMT

    [ 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

View raw message