Mailing-List: contact general-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: general@hadoop.apache.org
Received-SPF: neutral (athena.apache.org: 216.145.54.173 is neither permitted
 nor denied by domain of eric14@yahoo-inc.com)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1084)
Subject: Re: Thinking about the next hadoop mainline release
From: Eric Baldeschwieler <eric14@yahoo-inc.com>
In-Reply-To: <43D4BB64-1B14-45F6-941B-B65F31636266@apache.org>
Date: Fri, 17 Jun 2011 23:10:33 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <76BC80C1-7A3B-4B80-93C2-DBF1EF3152F0@yahoo-inc.com>
References: <EFF679DA-26AB-4250-8F59-A2330D0E3E5C@yahoo-inc.com>
 <BANLkTimX8gSQRFbVZaVDQBOSN9c4iRi=Nw@mail.gmail.com>
 <43D4BB64-1B14-45F6-941B-B65F31636266@apache.org>
To: "general@hadoop.apache.org" <general@hadoop.apache.org>

Hey Allen,

I agree with you that we should avoid future regressions like this.  I =
think the tradeoff that got security working well on one heavily used =
platform was the right one for hadoop-with-security, but I'll be sure to =
raise such issues for discussion in the future as soon as I become aware =
of them.

I agree that we should think about how to generalize the security work =
for other platforms.  That work is just waiting for someone to jump =
in....

On ganglia and the metrics framework, it would be great if you could put =
your head together with rajive and come up with a joint proposal on what =
docs / code is needed to fix the regression in a clean way.  That sounds =
like something we should be thinking about fixing in the 20 line and all =
future releases.

thanks,

E14


On Jun 17, 2011, at 10:33 AM, Allen Wittenauer wrote:

>=20
> On Jun 17, 2011, at 12:36 AM, Ryan Rawson wrote:
>=20
>> HDFS-918 and HDFS-347 are absolutely critical for random read
>> performance.  The smarter sites are already running HDFS-347 (I guess
>> they aren't running "Hadoop" then?), and soon they will be testing =
and
>> running HDFS-918 as well.  Opening 1 socket for every read just isn't
>> really scalable.
>=20
> 	Isn't "random read [on HDFS]" and "smarter sites" in the same =
breath an oxymoron?
>=20
>=20