# Frequently Asked Questions

# General

Why does -update not create the parent source-directory under a pre-existing target directory?
The behaviour of `-update` and `-overwrite` is described in detail in the Usage section of this document. In short, if either option is used with a pre-existing destination directory, the contents of each source directory is copied over, rather than the source-directory itself. This behaviour is consistent with the legacy DistCp implementation as well.
How does the new DistCp differ in semantics from the Legacy DistCp?

- Files that are skipped during copy used to also have their file-attributes (permissions, owner/group info, etc.) unchanged, when copied with Legacy DistCp. These are now updated, even if the file-copy is skipped.
- Empty root directories among the source-path inputs were not created at the target, in Legacy DistCp. These are now created.

Why does the new DistCp use more maps than legacy DistCp?

Legacy DistCp works by figuring out what files need to be actually copied to target before the copy-job is launched, and then launching as many maps as required for copy. So if a majority of the files need to be skipped (because they already exist, for example), fewer maps will be needed. As a consequence, the time spent in setup (i.e. before the M/R job) is higher.

The new DistCp calculates only the contents of the source-paths. It doesn't try to filter out what files can be skipped. That decision is put- off till the M/R job runs. This is much faster (vis-a-vis execution-time), but the number of maps launched will be as specified in the `-m` option, or 20 (default) if unspecified.

Why does DistCp not run faster when more maps are specified?

At present, the smallest unit of work for DistCp is a file. i.e., a file is processed by only one map. Increasing the number of maps to a value exceeding the number of files would yield no performance benefit. The number of maps lauched would equal the number of files.

Why does DistCp run out of memory?

If the number of individual files/directories being copied from the source path(s) is extremely large (e.g. 1,000,000 paths), DistCp might run out of memory while determining the list of paths for copy. This is not unique to the new DistCp implementation.

To get around this, consider changing the `-Xmx` JVM heap-size parameters, as follows:

`bash$ export HADOOP_CLIENT_OPTS="-Xms64m -Xmx1024m"`

`bash$ hadoop distcp /source /target`