[
https://issues.apache.org/jira/browse/HADOOP-17531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17285794#comment-17285794
]
Steve Loughran commented on HADOOP-17531:
-----------------------------------------
I think I'd have to spend tome time wondering about this. listFiles(path,
recursive=true) is the best for S3A, but it's mimiced in the other stores and
there's a risk they may be OOMing too (though I'm assuming they
depth-first-search)
* if stuff can be processed as it goes along, that *should* reduce problems,
though I do note your deadlock concerns.
* maybe we need a test FS which, at least as far as listings are concerned, can
simulate these directory trees. Some of the mock filesystems in existing tests
could act as a starting point here
> DistCp: Reduce memory usage on copying huge directories
> -------------------------------------------------------
>
> Key: HADOOP-17531
> URL: https://issues.apache.org/jira/browse/HADOOP-17531
> Project: Hadoop Common
> Issue Type: Improvement
> Reporter: Ayush Saxena
> Priority: Critical
>
> Presently distCp, uses the producer-consumer kind of setup while building the
> listing, the input queue and output queue are both unbounded, thus the
> listStatus grows quite huge.
> Rel Code Part :
> https://github.com/apache/hadoop/blob/trunk/hadoop-tools/hadoop-distcp/src/main/java/org/apache/hadoop/tools/SimpleCopyListing.java#L635
> This goes on bredth-first traversal kind of stuff(uses queue instead of
> earlier stack), so if you have files at lower depth, it will like open up the
> entire tree and the start processing....
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
