Return-Path: X-Original-To: apmail-hadoop-hdfs-issues-archive@minotaur.apache.org Delivered-To: apmail-hadoop-hdfs-issues-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id C3DF09E9D for ; Thu, 23 Aug 2012 12:02:43 +0000 (UTC) Received: (qmail 79983 invoked by uid 500); 23 Aug 2012 12:02:43 -0000 Delivered-To: apmail-hadoop-hdfs-issues-archive@hadoop.apache.org Received: (qmail 79823 invoked by uid 500); 23 Aug 2012 12:02:43 -0000 Mailing-List: contact hdfs-issues-help@hadoop.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: hdfs-issues@hadoop.apache.org Delivered-To: mailing list hdfs-issues@hadoop.apache.org Received: (qmail 79787 invoked by uid 99); 23 Aug 2012 12:02:42 -0000 Received: from arcas.apache.org (HELO arcas) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 23 Aug 2012 12:02:42 +0000 Received: from arcas.apache.org (localhost [127.0.0.1]) by arcas (Postfix) with ESMTP id 7382B2C0907 for ; Thu, 23 Aug 2012 12:02:42 +0000 (UTC) Date: Thu, 23 Aug 2012 23:02:42 +1100 (NCT) From: "Tsz Wo (Nicholas), SZE (JIRA)" To: hdfs-issues@hadoop.apache.org Message-ID: <628699121.5048.1345723362473.JavaMail.jiratomcat@arcas> In-Reply-To: <1478976591.1207.1333385124633.JavaMail.tomcat@hel.zones.apache.org> Subject: [jira] [Commented] (HDFS-3177) Allow DFSClient to find out and use the CRC type being used for a file. MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/HDFS-3177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13440227#comment-13440227 ] Tsz Wo (Nicholas), SZE commented on HDFS-3177: ---------------------------------------------- - The patch adds invoking callGetBlockLocations(..) in append. As a result, append additionally requires read permission. I think it is an unacceptable incompatible change. We need to think about this carefully. I suggest work on the append change in a separated JIRA. - For the changes in getFileChecksum(..), most of the changes is for refactoring callBlockChecksum(..). If we remove the append change here, let's also defer the refactoring so that it is easier to review. BTW, there is an unused "retry" variable in callBlockChecksum(..). > Allow DFSClient to find out and use the CRC type being used for a file. > ----------------------------------------------------------------------- > > Key: HDFS-3177 > URL: https://issues.apache.org/jira/browse/HDFS-3177 > Project: Hadoop HDFS > Issue Type: Bug > Components: data-node, hdfs client > Affects Versions: 0.23.0 > Reporter: Kihwal Lee > Assignee: Kihwal Lee > Fix For: 2.1.0-alpha, 3.0.0 > > Attachments: hdfs-3177-after-hadoop-8239-8240.patch.txt, hdfs-3177-after-hadoop-8239.patch.txt, hdfs-3177-branch2-trunk.patch.txt, hdfs-3177-branch2-trunk.patch.txt, hdfs-3177.patch, hdfs-3177-with-hadoop-8239-8240.patch.txt, hdfs-3177-with-hadoop-8239-8240.patch.txt, hdfs-3177-with-hadoop-8239-8240.patch.txt, hdfs-3177-with-hadoop-8239.patch.txt > > > To support HADOOP-8060, DFSClient should be able to find out the checksum type being used for files in hdfs. > In my prototype, DataTransferProtocol was extended to include the checksum type in the blockChecksum() response. DFSClient uses it in getFileChecksum() to determin the checksum type. Also append() can be configured to use the existing checksum type instead of the configured one. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira