Return-Path: Delivered-To: apmail-hadoop-hdfs-issues-archive@minotaur.apache.org Received: (qmail 38811 invoked from network); 17 Nov 2010 04:08:09 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 17 Nov 2010 04:08:09 -0000 Received: (qmail 1080 invoked by uid 500); 17 Nov 2010 04:08:40 -0000 Delivered-To: apmail-hadoop-hdfs-issues-archive@hadoop.apache.org Received: (qmail 768 invoked by uid 500); 17 Nov 2010 04:08:39 -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 752 invoked by uid 99); 17 Nov 2010 04:08:39 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 17 Nov 2010 04:08:39 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.22] (HELO thor.apache.org) (140.211.11.22) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 17 Nov 2010 04:08:36 +0000 Received: from thor (localhost [127.0.0.1]) by thor.apache.org (8.13.8+Sun/8.13.8) with ESMTP id oAH48En8020630 for ; Wed, 17 Nov 2010 04:08:15 GMT Message-ID: <12423311.136921289966894865.JavaMail.jira@thor> Date: Tue, 16 Nov 2010 23:08:14 -0500 (EST) From: "Patrick Kling (JIRA)" To: hdfs-issues@hadoop.apache.org Subject: [jira] Commented: (HDFS-1483) DFSClient.getBlockLocations returns BlockLocations with no indication that the corresponding blocks are corrupt In-Reply-To: <26515036.110951288230681119.JavaMail.jira@thor> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/HDFS-1483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12932805#action_12932805 ] Patrick Kling commented on HDFS-1483: ------------------------------------- [exec] -1 overall. [exec] [exec] +1 @author. The patch does not contain any @author tags. [exec] [exec] +1 tests included. The patch appears to include 3 new or modified tests. [exec] [exec] +1 javadoc. The javadoc tool did not generate any warning messages. [exec] [exec] +1 javac. The applied patch does not increase the total number of javac compiler warnings. [exec] [exec] -1 findbugs. The patch appears to introduce 3 new Findbugs warnings. [exec] [exec] -1 release audit. The applied patch generated 97 release audit warnings (more than the trunk's current 1 warnings). [exec] [exec] +1 system test framework. The patch passed system test framework compile. The findbugs/release audit warnings are not caused by this patch (see MAPREDUCE-2172). > DFSClient.getBlockLocations returns BlockLocations with no indication that the corresponding blocks are corrupt > --------------------------------------------------------------------------------------------------------------- > > Key: HDFS-1483 > URL: https://issues.apache.org/jira/browse/HDFS-1483 > Project: Hadoop HDFS > Issue Type: Bug > Components: hdfs client > Reporter: Patrick Kling > Assignee: Patrick Kling > Attachments: HDFS-1483.2.patch, HDFS-1483.patch > > > When there are no uncorrupted replicas of a block, FSNamesystem.getBlockLocations returns LocatedBlocks corresponding to corrupt blocks. When DFSClient converts these to BlockLocations, the information that the corresponding block is corrupt is lost. We should add a field to BlockLocation to indicate whether the corresponding block is corrupt in order to warn the client that reading this block will fail. This would be especially useful for tools such as RAID FSCK, which could then easily inspect whether data or parity blocks are corrupted without having to make direct RPC calls. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.