Mailing-List: contact mapreduce-dev-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: mapreduce-dev@hadoop.apache.org
Date: Thu, 14 Mar 2013 01:17:11 +0000 (UTC)
From: "Mithun Radhakrishnan (JIRA)" <jira@apache.org>
To: mapreduce-dev@hadoop.apache.org
Message-ID: <JIRA.12636934.1363223739476.438370.1363223831555@arcas>
In-Reply-To: <JIRA.12636934.1363223739476@arcas>
References: <JIRA.12636934.1363223739476@arcas>
Subject: [jira] [Created] (MAPREDUCE-5065) DistCp should skip checksum
 comparisons if block-sizes are different on source/target.
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Mithun Radhakrishnan created MAPREDUCE-5065:
-----------------------------------------------

             Summary: DistCp should skip checksum comparisons if block-sizes are different on source/target.
                 Key: MAPREDUCE-5065
                 URL: https://issues.apache.org/jira/browse/MAPREDUCE-5065
             Project: Hadoop Map/Reduce
          Issue Type: Bug
          Components: distcp
    Affects Versions: 0.23.5, 2.0.3-alpha
            Reporter: Mithun Radhakrishnan
            Assignee: Mithun Radhakrishnan


When copying files between 2 clusters with different default block-sizes, one sees that the copy fails with a checksum-mismatch, even though the files have identical contents.

The reason is that on HDFS, a file's checksum is unfortunately a function of the block-size of the file. So you could have 2 different files with identical contents (but different block-sizes) have different checksums. (Thus, it's also possible for DistCp to fail to copy files on the same file-system, if the source-file's block-size differs from HDFS default, and -pb isn't used.)

I propose that we skip checksum comparisons under the following conditions:
1. -skipCrc is specified.
2. File-size is 0 (in which case the call to the checksum-servlet is moot).
3. source.getBlockSize() != target.getBlockSize(), since the checksums are guaranteed to differ in this case.

I have a patch for #3.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira