[
https://issues.apache.org/jira/browse/MAPREDUCE-6166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14230407#comment-14230407
]
Eric Payne commented on MAPREDUCE-6166:
---------------------------------------
[~jira.shegalov], I'm sorry for not being clear.
{quote}
Can you clarify where in the code it's required to keep the original checksum?
Then this contents are written out using {{LocalFileSystem}}, which will create
again an on-disk checksum because it's based on {{ChecksumFileSystem}}.
{quote}
I don't think the {{IFile}} format is related to {{ChecksumFileSystem}}.
The {{IFile}} checksum is expected to be the last 4 bytes of the {{IFile}}, and
if we use {{input.read}} as below, those 4 bytes of checksum are not copied
into {{buf}}:
{code}
input = new IFileInputStream(input, compressedLength, conf);
// Copy data to local-disk
long bytesLeft = compressedLength - ((IFileInputStream)input).getSize();
try {
final int BYTES_TO_READ = 64 * 1024;
byte[] buf = new byte[BYTES_TO_READ];
while (bytesLeft > 0) {
int n = input.read(buf, 0, (int) Math.min(bytesLeft, BYTES_TO_READ));
...
{code}
However, if we use {{readWithChecksum}} as below, the checksum is copied into
{{buf}}:
{code}
input = new IFileInputStream(input, compressedLength, conf);
// Copy data to local-disk
long bytesLeft = compressedLength;
try {
final int BYTES_TO_READ = 64 * 1024;
byte[] buf = new byte[BYTES_TO_READ];
while (bytesLeft > 0) {
int n = ((IFileInputStream)input).read(buf, 0, (int)
Math.min(bytesLeft, BYTES_TO_READ));
...
{code}
Without those last 4 bytes of checksum on the end of the {{IFile}} format, the
final read will fail during the last merge pass with a chedksum error.
> Reducers do not catch bad map output transfers during shuffle if data
> shuffled directly to disk
> -----------------------------------------------------------------------------------------------
>
> Key: MAPREDUCE-6166
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-6166
> Project: Hadoop Map/Reduce
> Issue Type: Bug
> Components: mrv2
> Affects Versions: 2.6.0
> Reporter: Eric Payne
> Assignee: Eric Payne
> Attachments: MAPREDUCE-6166.v1.201411221941.txt,
> MAPREDUCE-6166.v2.201411251627.txt
>
>
> In very large map/reduce jobs (50000 maps, 2500 reducers), the intermediate
> map partition output gets corrupted on disk on the map side. If this
> corrupted map output is too large to shuffle in memory, the reducer streams
> it to disk without validating the checksum. In jobs this large, it could take
> hours before the reducer finally tries to read the corrupted file and fails.
> Since retries of the failed reduce attempt will also take hours, this delay
> in discovering the failure is multiplied greatly.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
