You are viewing a plain text version of this content. The canonical link for it is here.
Posted to hdfs-dev@hadoop.apache.org by stack <st...@duboce.net> on 2009/12/13 00:54:46 UTC

Commit hdfs-630 to 0.21?

HDFS-630 is kinda critical to us over in hbase.  We'd like to get it into
0.21 (Its been committed to TRUNK).  Its probably hard to argue its a
blocker for 0.21.  We could run a vote.  Or should we just file it against
0.21.1 hdfs and commit it after 0.21 goes out?  What would folks suggest?

Without it, a node crash (datanode+regionserver) will bring down a second
regionserver, particularly if the cluster is small (See HBASE-1876 for
description of the play-by-play where NN keeps giving out dead DN as place
to locate new blocks).  Since the bulk of hbase clusters are small --
whether evaluations, test, or just small productions -- this issue is an
important fix for us.  If the cluster is of 5 or less nodes, we'll probably
recover but there'll be a period of churn.  At a minimum mapreduce jobs
running against the cluster will fail (usually some kind of bullk upload).

St.Ack

Re: Commit hdfs-630 to 0.21?

Posted by Dhruba Borthakur <dh...@gmail.com>.
If HDFS-630 is a blocker for hbase on small clusters, maybe we can target it
for 0.21. Maybe you can run a VOTE for it?

thanks,
dhruba


On Sat, Dec 12, 2009 at 3:54 PM, stack <st...@duboce.net> wrote:

> HDFS-630 is kinda critical to us over in hbase.  We'd like to get it into
> 0.21 (Its been committed to TRUNK).  Its probably hard to argue its a
> blocker for 0.21.  We could run a vote.  Or should we just file it against
> 0.21.1 hdfs and commit it after 0.21 goes out?  What would folks suggest?
>
> Without it, a node crash (datanode+regionserver) will bring down a second
> regionserver, particularly if the cluster is small (See HBASE-1876 for
> description of the play-by-play where NN keeps giving out dead DN as place
> to locate new blocks).  Since the bulk of hbase clusters are small --
> whether evaluations, test, or just small productions -- this issue is an
> important fix for us.  If the cluster is of 5 or less nodes, we'll probably
> recover but there'll be a period of churn.  At a minimum mapreduce jobs
> running against the cluster will fail (usually some kind of bullk upload).
>
> St.Ack
>



-- 
Connect to me at http://www.facebook.com/dhruba