hadoop-hdfs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tsz Wo Sze <szets...@yahoo.com>
Subject Re: VOTE: HDFS-347 merge
Date Wed, 03 Apr 2013 06:47:07 GMT
Hi Colin,

Thanks for filing HDFS-4661.  Will watch it.

For the latest patch in HDFS-347, it seems that there are still bugs in the patch.  I have
posted some comments on HDFS-347.  


Thanks again.

Nicholas



________________________________
 From: Colin McCabe <cmccabe@alumni.cmu.edu>
To: hdfs-dev@hadoop.apache.org 
Sent: Wednesday, April 3, 2013 1:38 AM
Subject: Re: VOTE: HDFS-347 merge
 
On Mon, Apr 1, 2013 at 6:58 PM, Colin McCabe <cmccabe@alumni.cmu.edu> wrote:

> On Mon, Apr 1, 2013 at 5:04 PM, Suresh Srinivas <suresh@hortonworks.com>wrote:
>
>> Colin,
>>
>> For the record, the last email in the previous thread in ended with the
>> following comment from Nicholas:
>> > It is great to hear that you agree to keep HDFS-2246.  Please as well
>> address my comments posted on HDFS-347 and let me know once you have
>> posted
>> a new patch on HDFS-347.
>>
>>
> Hi Nicholas,
>
> Can you please open a JIRA listing what you think should be fixed or
> changed, and why?
>
> Also please specify whether it is important to fix this before the merge,
> and if so, why.  If this is a minor style change, or renaming function X to
> Y, then I think we can easily do it after the merge.
>
> thanks,
> Colin
>
>
Hi Nicholas,

I opened https://issues.apache.org/jira/browse/HDFS-4661 with some of the
style fixes that you suggested in HDFS-347.  If there is anything else you
would like to see addressed before the merge, please add it to this JIRA.

thanks,
Colin



>
>
>> I did not see any response (unless I missed it). Can you please address
>> it?
>>
>> Regards,
>> Suresh
>>
>>
>> On Mon, Apr 1, 2013 at 4:32 PM, Colin McCabe <cmccabe@alumni.cmu.edu>
>> wrote:
>>
>> > Hi all,
>> >
>> > I think it's time to merge the HDFS-347 branch back to trunk.  It's been
>> > under
>> > review and testing for several months, and provides both a performance
>> > advantage, and the ability to use short-circuit local reads without
>> > compromising system security.
>> >
>> > Previously, we tried to merge this and the objection was brought up
>> that we
>> > should keep the old, insecure short-circuit local reads around so that
>> > platforms for which secure SCR had not yet been implemented could use it
>> > (e.g. Windows).  This has been addressed-- see HDFS-4538 for details.
>> >  Suresh has also volunteered to maintain the insecure SCR code until
>> secure
>> > SCR can be implemented for Windows.
>> >
>> > Please cast your vote by EOD Monday 4/8.
>> >
>> > best,
>> > Colin
>> >
>>
>>
>>
>> --
>> http://hortonworks.com/download/
>>
>
>
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message