Looking it the patch it isn't obvious that this port should create any extra
verification effort from the quality standpoint. Thus, it won't delay 0.21
release, IMO.
+1 to back port it.
--
With best regards,
Konstantin Boudnik (aka Cos)
Yahoo! Grid Computing
+1 (408) 349-4049
2CAC 8312 4870 D885 8616 6115 220F 6980 1F27 E622
Attention! Streams of consciousness are disallowed
On 11/25/09 12:46 , Allen Wittenauer wrote:
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"<s29752-hadoop...@yahoo.com>
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<jho...@yahoo-inc.com>
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
