[
https://issues.apache.org/jira/browse/HADOOP-15281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16742311#comment-16742311
]
Andrew Olson edited comment on HADOOP-15281 at 1/14/19 5:10 PM:
----------------------------------------------------------------
We've successfully tested a simple solution where in the
{{RetriableFileCopyCommand}} class, renames are specifically avoided for any
S3A target destinations in {{doCopy}} - I'm not sure there are cases where it's
actually beneficial or desirable when writing to S3. The gist of the logic
change is,
{noformat}
final boolean toAppend = action == FileAction.APPEND;
final boolean directWriteToS3 =
target.toUri().getScheme().equals("s3a");
final boolean useTmpTarget = !toAppend && !directWriteToS3;
Path targetPath = useTmpTarget ? getTmpFile(target, context) : target;
{noformat}
(Then replacing a couple instances of {{!toAppend}} with {{useTmpTarget}} later
on in the method)
If that's a viable & reasonable solution I can work on a patch with that change
and the corresponding test and docs updates. Otherwise design guidance would be
appreciated for how and where to add the write-directly / no-rename
configuration option.
was (Author: noslowerdna):
We've successfully tested a quick+dirty solution where in the
RetriableFileCopyCommand class, renames are specifically avoided for any S3A
target destinations in {{doCopy}} - I'm not sure there are cases where it's
actually beneficial or desirable when writing to S3. The gist of the logic is
simply,
{noformat}
final boolean toAppend = action == FileAction.APPEND;
final boolean directWriteToS3 =
target.toUri().getScheme().equals("s3a");
final boolean useTmpTarget = !toAppend && !directWriteToS3;
Path targetPath = useTmpTarget ? getTmpFile(target, context) : target;
{noformat}
(Then replacing a couple instances of {{!toAppend}} with {{useTmpTarget}} later
on in the method)
If that's a viable & reasonable solution I can work on a patch with that change
and the corresponding test/docs updates. Otherwise design guidance would be
appreciated for how and where to add the write-directly no-rename configuration
option.
> Distcp to add no-rename copy option
> -----------------------------------
>
> Key: HADOOP-15281
> URL: https://issues.apache.org/jira/browse/HADOOP-15281
> Project: Hadoop Common
> Issue Type: Improvement
> Components: tools/distcp
> Affects Versions: 3.0.0
> Reporter: Steve Loughran
> Priority: Major
>
> Currently Distcp uploads a file by two strategies
> # append parts
> # copy to temp then rename
> option 2 executes the following sequence in {{promoteTmpToTarget}}
> {code}
> if ((fs.exists(target) && !fs.delete(target, false))
> || (!fs.exists(target.getParent()) && !fs.mkdirs(target.getParent()))
> || !fs.rename(tmpTarget, target)) {
> throw new IOException("Failed to promote tmp-file:" + tmpTarget
> + " to: " + target);
> }
> {code}
> For any object store, that's a lot of HTTP requests; for S3A you are looking
> at 12+ requests and an O(data) copy call.
> This is not a good upload strategy for any store which manifests its output
> atomically at the end of the write().
> Proposed: add a switch to write direct to the dest path. either a conf option
> or a CLI option
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
