Mailing-List: contact hdfs-dev-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: hdfs-dev@hadoop.apache.org
Received-SPF: pass (athena.apache.org: domain of lars.george@gmail.com
 designates 209.85.219.214 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :cc:content-type;
        b=fYfwb1YJvSXAVOfppdf94oRsPJvKiNNjcUTNKEWXzEnxG8ctfXOyvhqehKuNJ41dqn
         5isQKDBGp89e1v8q84YHhV6tKuyhBmpcbkapN2T2V405n6Eerytr6sgEVq22+5mnfs0j
         RPVS2Au+AjC0VVW3YPC7EehmlUnMk6KZ7+bQE=
MIME-Version: 1.0
In-Reply-To: <31a243e70912142353g1c518565pd5f4870382f1fb1b@mail.gmail.com>
References: <914611.19919.qm@web65513.mail.ac4.yahoo.com>
	 <31a243e70912142353g1c518565pd5f4870382f1fb1b@mail.gmail.com>
Date: Tue, 15 Dec 2009 09:44:40 +0100
Message-ID: <61770b880912150044v21d2e70dp3f9bebfab95f695a@mail.gmail.com>
Subject: Re: Commit hdfs-630 to 0.21?
From: Lars George <lars.george@gmail.com>
To: hbase-dev@hadoop.apache.org
Cc: hdfs-dev@hadoop.apache.org
Content-Type: multipart/alternative; boundary=00c09f8fea8c96737b047ac06668

--00c09f8fea8c96737b047ac06668
Content-Type: text/plain; charset=ISO-8859-1

+1

Lars

On Tue, Dec 15, 2009 at 8:53 AM, Jean-Daniel Cryans <jdcryans@apache.org>wrote:

> +1 for 0.21.0
>
> J-D
>
> On Mon, Dec 14, 2009 at 11:30 PM, Andrew Purtell <apurtell@apache.org>
> wrote:
> > +1
> >
> >
> > On Sat, Dec 12, 2009 at 3:54 PM, stack <stack@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
> >>
> >
> >
> >
>

--00c09f8fea8c96737b047ac06668--