[
https://issues.apache.org/jira/browse/HADOOP-13600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16324725#comment-16324725
]
Steve Loughran commented on HADOOP-13600:
-----------------------------------------
Not looked at this for a while, I'll try and take a look in detail, especially
now the committer is merged in.
One thing I've realised is our copy operation isn't doing what we do elsewhere;
shuffle the list of files so there's more scattering of workload across shards
in the bucket, so less risk of throttling.
* from the list, grab the first batch to copy (say, same amount as we can
delete in a single batch)
* pick out the first few largest files to start copying first
* shuffle the rest of the batch
This is what I've done in
[cloudup|https://github.com/steveloughran/cloudup/blob/master/src/main/java/org/apache/hadoop/tools/cloudup/Cloudup.java]
and I believe it makes for a fast upload
> S3a rename() to copy files in a directory in parallel
> -----------------------------------------------------
>
> Key: HADOOP-13600
> URL: https://issues.apache.org/jira/browse/HADOOP-13600
> Project: Hadoop Common
> Issue Type: Sub-task
> Components: fs/s3
> Affects Versions: 2.7.3
> Reporter: Steve Loughran
> Assignee: Sahil Takiar
> Attachments: HADOOP-13600.001.patch
>
>
> Currently a directory rename does a one-by-one copy, making the request
> O(files * data). If the copy operations were launched in parallel, the
> duration of the copy may be reducable to the duration of the longest copy.
> For a directory with many files, this will be significant
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
