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 0F83B90CC for ; Wed, 7 Mar 2012 22:57:21 +0000 (UTC) Received: (qmail 76580 invoked by uid 500); 7 Mar 2012 22:57:20 -0000 Delivered-To: apmail-hadoop-hdfs-issues-archive@hadoop.apache.org Received: (qmail 76531 invoked by uid 500); 7 Mar 2012 22:57:20 -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 76276 invoked by uid 99); 7 Mar 2012 22:57:20 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 07 Mar 2012 22:57:20 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=5.0 tests=ALL_TRUSTED,T_RP_MATCHES_RCVD X-Spam-Check-By: apache.org Received: from [140.211.11.116] (HELO hel.zones.apache.org) (140.211.11.116) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 07 Mar 2012 22:57:18 +0000 Received: from hel.zones.apache.org (hel.zones.apache.org [140.211.11.116]) by hel.zones.apache.org (Postfix) with ESMTP id 48F1DD0A6 for ; Wed, 7 Mar 2012 22:56:57 +0000 (UTC) Date: Wed, 7 Mar 2012 22:56:57 +0000 (UTC) From: "Eli Collins (Commented) (JIRA)" To: hdfs-issues@hadoop.apache.org Message-ID: <958700930.36759.1331161017300.JavaMail.tomcat@hel.zones.apache.org> In-Reply-To: <1259796423.14836.1314301470826.JavaMail.tomcat@hel.zones.apache.org> Subject: [jira] [Commented] (HDFS-2288) Replicas awaiting recovery should return a full visible length 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-2288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13224813#comment-13224813 ] Eli Collins commented on HDFS-2288: ----------------------------------- Hey Todd, I think you're right, there's a bug in the way visible length is calculated. My understanding of visible length is "the length that all datanodes in the pipeline contain at least such amount of data." (HDFS-814), and given that RBW#getVisibleLength returns getBytesAcked() and not all DNs necessarily have the same # bytes Ack'd, they could disagree on the visible length of the replica. That being said, aside from this bug (and potentially others) the intent / goal should be to maintain this property right? What's the case in HBase that can hit this, it's reading a file that's recovering its pipeline that is also under lease recovery? Thanks, Eli > Replicas awaiting recovery should return a full visible length > -------------------------------------------------------------- > > Key: HDFS-2288 > URL: https://issues.apache.org/jira/browse/HDFS-2288 > Project: Hadoop HDFS > Issue Type: Bug > Components: data-node > Affects Versions: 0.23.0 > Reporter: Todd Lipcon > Assignee: Todd Lipcon > Priority: Critical > Fix For: 0.24.0 > > Attachments: hdfs-2288.txt > > > Currently, if the client calls getReplicaVisibleLength for a RWR, it returns a visible length of 0. This causes one of HBase's tests to fail, and I believe it's incorrect behavior. -- 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