Mailing-List: contact common-user-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: common-user@hadoop.apache.org
Received-SPF: pass (athena.apache.org: domain of stas.oskin@gmail.com
 designates 209.85.220.222 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
         :content-type;
        b=tLAMKjftwkhg3LS3FHEZoHXOJbgB/cEW+lFtZQaUXh3u2WteJAhZeDnUK9xonzZ/Ac
         Fa/DsictEIZxysaF+qOjUkjrM8B82ak5CyWfTvrulQQzrGOgKCobooI137UoobJE3F8p
         JCuq2nv2x2VovanPs1hGWnhcYwOJXNImIK0qA=
MIME-Version: 1.0
In-Reply-To: <77938bc20909230021g415a45d5gfcb52f1772f0c7e9@mail.gmail.com>
References: <77938bc20905240533v3f1ff7c9s7ca005ff7c9b5a92@mail.gmail.com>
	 <ac79ea400905250332s170d0c4fseed8eea4a9a83d26@mail.gmail.com>
	 <77938bc20905250340o2a7f60c8v548e123ae3be365e@mail.gmail.com>
	 <77938bc20909130308n30e6017fubce1900b039eba29@mail.gmail.com>
	 <56B06038-B1B2-427E-BC6B-759CAA7F2294@apache.org>
	 <77938bc20909201558m22400b02kda23cd341a8ee5e9@mail.gmail.com>
	 <d6d7c4410909221550y7198ca9aw42cd05475fd4a0cb@mail.gmail.com>
	 <77938bc20909230021g415a45d5gfcb52f1772f0c7e9@mail.gmail.com>
Date: Wed, 23 Sep 2009 10:28:19 +0300
Message-ID: <77938bc20909230028l165b4312g137188be23c7bbd3@mail.gmail.com>
Subject: Re: RandomAccessFile with HDFS
From: Stas Oskin <stas.oskin@gmail.com>
To: common-user@hadoop.apache.org
Content-Type: multipart/alternative; boundary=00151747868eb39aff047439a8ca

--00151747868eb39aff047439a8ca
Content-Type: text/plain; charset=ISO-8859-1

By the way, something that I forgot to ask before:

Will the append implementation be as fast, as the write/copy functions?

Regards.

2009/9/23 Stas Oskin <stas.oskin@gmail.com>

> Thanks, I exactly wanted to ask this for our R&D roadmap.
>
> 2009/9/23 Aaron Kimball <aaron@cloudera.com>
>
> Or maybe more pessimistically, the second "stable" append implementation.
>>
>> It's not like HADOOP-1700 wasn't intended to work. It was just found not
>> to
>> after the fact. Hopefully this reimplementation will succeed. If you're
>> running a cluster that contains mission-critical data that cannot tolerate
>> corruption or loss, you shouldn't jump on the new-feature bandwagon until
>> it's had time to prove itself in the wild.
>>
>> But yes, we hope that appends will really-truly work in 0.21.
>> Experimental/R&D projects should be able to plan on having a working
>> append
>> function in 0.21.
>>
>> - Aaron
>>
>> On Sun, Sep 20, 2009 at 3:58 PM, Stas Oskin <stas.oskin@gmail.com> wrote:
>>
>> > Hi.
>> >
>> > Just to understand the road-map, 0.21 will be the first stable "append"
>> > implementation?
>> >
>> > Regards.
>> >
>> > 2009/9/20 Owen O'Malley <omalley@apache.org>
>> >
>> > >
>> > > On Sep 13, 2009, at 3:08 AM, Stas Oskin wrote:
>> > >
>> > >  Hi.
>> > >>
>> > >> Any idea when the "append" functionality is expected?
>> > >>
>> > >
>> > > A working append is a blocker on HDFS 0.21.0.
>> > >
>> > > The code for append is expected to be complete in a few weeks.
>> Meanwhile,
>> > > the rest of Common, HDFS, and MapReduce have feature-frozen and need
>> to
>> > be
>> > > stabilized and all of the critical bugs fixed. I'd expect the first
>> > releases
>> > > of 0.21.0 in early November.
>> > >
>> > > -- Owen
>> > >
>> >
>>
>

--00151747868eb39aff047439a8ca--