Return-Path: Delivered-To: apmail-hadoop-hdfs-issues-archive@minotaur.apache.org Received: (qmail 87144 invoked from network); 24 Aug 2010 23:19:37 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 24 Aug 2010 23:19:37 -0000 Received: (qmail 80530 invoked by uid 500); 24 Aug 2010 23:19:37 -0000 Delivered-To: apmail-hadoop-hdfs-issues-archive@hadoop.apache.org Received: (qmail 80459 invoked by uid 500); 24 Aug 2010 23:19:37 -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 80451 invoked by uid 99); 24 Aug 2010 23:19:37 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 24 Aug 2010 23:19:37 +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; Tue, 24 Aug 2010 23:19:36 +0000 Received: from thor (localhost [127.0.0.1]) by thor.apache.org (8.13.8+Sun/8.13.8) with ESMTP id o7ONJGol028026 for ; Tue, 24 Aug 2010 23:19:16 GMT Message-ID: <13450361.544561282691956223.JavaMail.jira@thor> Date: Tue, 24 Aug 2010 19:19:16 -0400 (EDT) From: "Konstantin Shvachko (JIRA)" To: hdfs-issues@hadoop.apache.org Subject: [jira] Commented: (HDFS-1351) Make it possible for BlockPlacementPolicy to return null In-Reply-To: <4239133.525791282634716856.JavaMail.jira@thor> 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-1351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12902146#action_12902146 ] Konstantin Shvachko commented on HDFS-1351: ------------------------------------------- Deletion hint is the Balancer logic. Balancer copied a replica to another node, and is requesting to delete the source replica. So if chooseReplicaToDelete() would ever intentionally return null, the delHint will be lost, and balancing will be only increasing block replication in your use case. I am a bit confused that you state this as a a step in future work, rather than a bug. Your test fails on current trunk with NullPointerException because chooseReplicaToDelete() returned null, right? And this seems to be an attempt to fix it. It is good to fix bugs. If it is intended as a bug fix, then you can fix it without changing the order of choosing replicas. If not, then it would be really good if you elaborate on why do you need this. Why e.g. just bringing the NN into safe mode doesn't work. Basically I am wondering what is coming next, what is the design of this hypothetical feature. Is there an intention to build one soon. > Make it possible for BlockPlacementPolicy to return null > -------------------------------------------------------- > > Key: HDFS-1351 > URL: https://issues.apache.org/jira/browse/HDFS-1351 > Project: Hadoop HDFS > Issue Type: Test > Components: name-node > Affects Versions: 0.22.0 > Reporter: Dmytro Molkov > Assignee: Dmytro Molkov > Attachments: HDFS-1351.patch > > > The idea is to modify FSNamesystem.chooseExcessReplicates code, so it can accept a null return from chooseReplicaToDelete which will indicate that NameNode should not be deleting extra replicas. > One possible usecase - if there are nodes being added to the cluster that might have corrupt replicas on them you do not want to delete other replicas until the block scanner finished scanning every block on the datanode. > This will require additional work on the implementation of the BlockPlacementPolicy, but with this JIRA I just wanted to create a basis for future improvements. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.