[
https://issues.apache.org/jira/browse/HDFS-202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12893832#action_12893832
]
Suresh Srinivas commented on HDFS-202:
--------------------------------------
# HDFS.java
#* Not sure about "NB:" in the comment
#* DirListingIterator
#** make f, src, needLocation final. Add javadoc to the class.
#** getNext() should call hasNext(). A caller calling next() without calling
hasNext() could result in not fetching new partial list and also
ArrayIndexOutOfBoundsExeption.
# DistributedFileSystem
#* listLocatedStatus() make {{src}} final.
#* listFiles() make {{itor}}, {{curFile}} private and {{dirStats}} final.
# HDFSFileLocatedStatus.java - missing banner.
# FSNamesystem.java - make getBlockLocationsInternal() private
# NameNode.java - change variable hasLocation to needLocation. Method
getListing() variant with boolean flag is just used by fsck? Do we need that
variant?
# General - as in hadoop common implementation, on IOException, should next()
and hasNext() throw RuntimeException instead of returning false. Please note
the comment in HADOOP-6870 about if this is right way to handle
FileNotFoundException.
> Add a bulk FIleSystem.getFileBlockLocations
> -------------------------------------------
>
> Key: HDFS-202
> URL: https://issues.apache.org/jira/browse/HDFS-202
> Project: Hadoop HDFS
> Issue Type: New Feature
> Reporter: Arun C Murthy
> Assignee: Hairong Kuang
> Fix For: 0.22.0
>
> Attachments: hdfsListFiles.patch, hdfsListFiles1.patch
>
>
> Currently map-reduce applications (specifically file-based input-formats) use
> FileSystem.getFileBlockLocations to compute splits. However they are forced
> to call it once per file.
> The downsides are multiple:
> # Even with a few thousand files to process the number of RPCs quickly
> starts getting noticeable
> # The current implementation of getFileBlockLocations is too slow since
> each call results in 'search' in the namesystem. Assuming a few thousand
> input files it results in that many RPCs and 'searches'.
> It would be nice to have a FileSystem.getFileBlockLocations which can take in
> a directory, and return the block-locations for all files in that directory.
> We could eliminate both the per-file RPC and also the 'search' by a 'scan'.
> When I tested this for terasort, a moderate job with 8000 input files the
> runtime halved from the current 8s to 4s. Clearly this is much more important
> for latency-sensitive applications...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
