You are viewing a plain text version of this content. The canonical link for it is here.
Posted to common-dev@hadoop.apache.org by "Doug Cutting (JIRA)" <ji...@apache.org> on 2009/06/02 01:03:07 UTC
[jira] Commented: (HADOOP-5795) Add a bulk
FIleSystem.getFileBlockLocations
[ https://issues.apache.org/jira/browse/HADOOP-5795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12715295#action_12715295 ]
Doug Cutting commented on HADOOP-5795:
--------------------------------------
> But not sure why it returns a map
It could perhaps instead return an array of two-element structs, each containing a filestatis/blocklocations pair, but a Map seems simpler.
> How does a user figure out which were valid and which were invalid/non-existent/empty paths?
Non-existent paths should be ignored. Paths whose URIs are for different filesystems or are somehow unparseable should cause an exception.
> Add a bulk FIleSystem.getFileBlockLocations
> -------------------------------------------
>
> Key: HADOOP-5795
> URL: https://issues.apache.org/jira/browse/HADOOP-5795
> Project: Hadoop Core
> Issue Type: New Feature
> Components: dfs
> Affects Versions: 0.20.0
> Reporter: Arun C Murthy
> Assignee: Jakob Homan
> Fix For: 0.21.0
>
>
> 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.