[
https://issues.apache.org/jira/browse/HADOOP-11034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14134492#comment-14134492
]
Gera Shegalov commented on HADOOP-11034:
----------------------------------------
We have also discussed an option to have a recursive getStatus. I am not sure
if you want to do it in a separate JIRA.
Recursion will will traverse internal viewfs dirs with mount points as base,
and where each internal inode sums the results from its child nodes.
An edge case is when the user has the same fs mounted multiple times. This can
be avoided by keeping track of resolved fs during recursion. Even more complex
edge case than this is when the same FS is mounted via different abstractions,
e.g., as WebHDFS, Hftp and HDFS at the same time. One can have certain
heuristics regarding identical authorities, etc. Initially we can have a
boolean conf enabling collecting status recursively. It will be off by default.
Then users who don't have multiple logically equivalent mount points will set
it to true.
> ViewFileSystem is missing getStatus(Path)
> -----------------------------------------
>
> Key: HADOOP-11034
> URL: https://issues.apache.org/jira/browse/HADOOP-11034
> Project: Hadoop Common
> Issue Type: Bug
> Components: viewfs
> Reporter: Gary Steelman
> Attachments: HADOOP-11034-trunk-1.patch, HADOOP-11034.2.patch
>
>
> This patch implements ViewFileSystem#getStatus(Path), which is currently
> unimplemented.
> getStatus(Path) should return the FsStatus of the FileSystem backing the
> path. Currently it returns the same as getStatus(), which is a default
> Long.MAX_VALUE for capacity, 0 used, and Long.MAX_VALUE for remaining space.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
