[HDFS-9705] Refine the behaviour of getFileChecksum when length = 0

• Type: Improvement
• Status: Resolved
• Priority: Minor
• Resolution: Fixed
• Fix Version/s: 2.9.0, 3.0.0-alpha4, 2.8.2
• Assignee: Sammi Chen
• Reporter: Kai Zheng
• Created: 26/Jan/16 10:43
• Updated: 07/Jun/17 23:56
• Resolved: 29/Mar/17 04:41

Description

FileSystem#getFileChecksum may accept length parameter and 0 is a valid value. Currently it will return null when length is 0, in the following code block:

    //compute file MD5
    final MD5Hash fileMD5 = MD5Hash.digest(md5out.getData());
    switch (crcType) {
    case CRC32:
      return new MD5MD5CRC32GzipFileChecksum(bytesPerCRC,
          crcPerBlock, fileMD5);
    case CRC32C:
      return new MD5MD5CRC32CastagnoliFileChecksum(bytesPerCRC,
          crcPerBlock, fileMD5);
    default:
      // If there is no block allocated for the file,
      // return one with the magic entry that matches what previous
      // hdfs versions return.
      if (locatedblocks.size() == 0) {
        return new MD5MD5CRC32GzipFileChecksum(0, 0, fileMD5);
      }

      // we should never get here since the validity was checked
      // when getCrcType() was called above.
      return null;
    }

The comment says "we should never get here since the validity was checked" but it does. As we're using the MD5-MD5-X approach, and EMPTY--CONTENT actually is a valid case in which the MD5 value is d41d8cd98f00b204e9800998ecf8427e, so suggest we return a reasonable value other than null. At least some useful information in the returned value can be seen, like values from block checksum header.

Issue Links

• relates to: HDFS-8430 Erasure coding: compute file checksum for striped files (stripe by stripe)