[
https://issues.apache.org/jira/browse/HADOOP-13600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15705228#comment-15705228
]
Steve Loughran commented on HADOOP-13600:
-----------------------------------------
yeah, looking at my patch I'm not sure if there's much of it worth preserving.
I'd realised it had got over complex. How about you sync your patch up with
HADOOP-13823 and we start from there. Elsewhere (HADOOP-13786) I'm doing a
special committer for s3, which is going to directly call innerRename() & so
relay failures up immediately.
Failures on renames is going to be fun;
# I can think of a test for that but it will be fairly brittle: create two
large files, have a thread size of 1 for the copies, delete the 2nd while the
first copy is in progress but after the listing has started. Or: start playing
with mocks via the plug in AWS client code; have something which explicitly
triggers failures on copy requests.
# I do want at least the first copy failure to be propagated up to the caller;
usually it is that first failure which is most interesting.
> 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: Steve Loughran
>
> 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.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
