From common-dev-return-72960-apmail-hadoop-common-dev-archive=hadoop.apache.org@hadoop.apache.org Wed Nov 25 20:47:58 2009 Return-Path: Delivered-To: apmail-hadoop-common-dev-archive@www.apache.org Received: (qmail 27556 invoked from network); 25 Nov 2009 20:47:57 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 25 Nov 2009 20:47:57 -0000 Received: (qmail 38143 invoked by uid 500); 25 Nov 2009 20:47:56 -0000 Delivered-To: apmail-hadoop-common-dev-archive@hadoop.apache.org Received: (qmail 38067 invoked by uid 500); 25 Nov 2009 20:47:56 -0000 Mailing-List: contact common-dev-help@hadoop.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: common-dev@hadoop.apache.org Delivered-To: mailing list common-dev@hadoop.apache.org Received: (qmail 38057 invoked by uid 99); 25 Nov 2009 20:47:56 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 25 Nov 2009 20:47:56 +0000 X-ASF-Spam-Status: No, hits=-4.0 required=10.0 tests=RCVD_IN_DNSWL_MED,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of awittenauer@linkedin.com designates 69.28.149.25 as permitted sender) Received: from [69.28.149.25] (HELO esv4-mav03.corp.linkedin.com) (69.28.149.25) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 25 Nov 2009 20:47:44 +0000 DomainKey-Signature: s=prod; d=linkedin.com; c=nofws; q=dns; h=X-IronPort-AV:Received:User-Agent:Date:Subject:From:To: Message-ID:Thread-Topic:Thread-Index:In-Reply-To: Mime-version:Content-type:Content-transfer-encoding; b=DB/+CrfE8FssT61RZ6hKLz76sBrweb5rMZ/zcj6sngcQFdpA3u7XUTDK /BVNkRk9+WE5mZR9uyJERRRWjHU/R9hCQHdinfbmFeZrTHsg+8d1F/8QO zKTtxGf5v7uGO8+; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=linkedin.com; i=awittenauer@linkedin.com; q=dns/txt; s=proddkim; t=1259182064; x=1290718064; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Allen=20Wittenauer=20 |Subject:=20Re:=20HDFS-758=20in=20Hadoop-21=20,=20Updates =20to=20=20Namenode=20health=20page|Date:=20Wed,=2025=20N ov=202009=2012:46:30=20-0800|Message-ID:=20|To:=20|Mime-version:=201.0|Content-transfer-encoding:=207 bit|In-Reply-To:=20<80244.28195.qm@web56202.mail.re3.yaho o.com>; bh=DiWEPjW640w03AnO1wEStVOt7ZmYQ8RBpZJdBNlSb7s=; b=cp9vhgrRtlungyU1pNdZeRSaQPEr53zi83ciYO72/TKRAC5FgFQMwT6K Cpii9g+z62y7HNt5pIw7ZzbCRtkox/nQ7lFuC3mMrTnIGb6n4xFYRR4xc p+mdvu7GRSIMWo5; X-IronPort-AV: E=Sophos;i="4.47,288,1257148800"; d="scan'208";a="9676612" Received: from 172.18.36.31 ([172.18.36.31]) by CORP-MAIL.linkedin.biz ([172.18.46.135]) via Exchange Front-End Server mail-access.linkedin.biz ([172.18.46.133]) with Microsoft Exchange Server HTTP-DAV ; Wed, 25 Nov 2009 20:46:31 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Wed, 25 Nov 2009 12:46:30 -0800 Subject: Re: HDFS-758 in Hadoop-21 , Updates to Namenode health page From: Allen Wittenauer To: Message-ID: Thread-Topic: HDFS-758 in Hadoop-21 , Updates to Namenode health page Thread-Index: AcpuEF11sZtQ3N5660uEouf008qm9w== In-Reply-To: <80244.28195.qm@web56202.mail.re3.yahoo.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Then you'll have no issues patching other things in 0.21 that are actual bug fixes that also meet this criteria, right? Or does this only apply to things that Yahoo! is hitting/deemed worthy? On 11/25/09 12:03 PM, "Tsz Wo (Nicholas), Sze" wrote: > +1 on committing it to 0.21 > > I also agree that it does not impact the 0.21 release since the patch is > already done. The argument of not committing it to 0.21 would be either (1) > the patch is not safe, or (2) the patch is not that useful. I don't see they > are the cases here. > > Nicholas Sze > > > > > ----- Original Message ---- >> From: Jakob Homan >> To: common-dev@hadoop.apache.org >> Sent: Wed, November 25, 2009 11:31:08 AM >> Subject: Re: HDFS-758 in Hadoop-21 , Updates to Namenode health page >> >> +1. Backporting this does not in any way impact the release of 21. >> -Jakob >> Hairong Kuang wrote: >>> +1. Although this is a new feature, I'd like to have it committed to 0.21 >>> since we have so many issues with delayed decomission recently. >>> >>> Hairong >>> >>> >>> On 11/24/09 6:06 PM, "Suresh Srinivas" wrote: >>> >>>> +1. This will also help debug the issues when decommissioning takes a long >>>> time to complete. >>>> >>>> >>>> On 11/23/09 7:36 PM, "Jitendra Nath Pandey" wrote: >>>> >>>> >>>> >>>>> Hi, >>>>>> We will be committing some changes to the Namenode Health page >>>>>> (dfshealth.jsp) as part of the fix in HDFS-758. This will enable us to >>>>>> monitor the progress of decommissioning of datanodes more effectively. >>>>>> Summary of changes : >>>>>> 1. A new link on the page for Decommissioning nodes. >>>>>> 2. This link will point to a new page with details about >>>>>> decommissioning >>>>>> status for each node which include >>>>>> a) Number of under-relplicated blocks in the node. >>>>>> b) Number of blocks with only no live replica (i.e. All its >> replicas >>>>>> are on decommissioning nodes). >>>>>> c) Number of under-replicated blocks in open files. >>>>>> d) Time since decommissioning started. >>>>>> 3. The main page will also contain total number of under-replicated >>>>>> blocks >>>>>> in the cluster. >>>>>> >>>>>> Thanks >>>>>> jitendra >>>> >>> >