Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Threaded View
HDFS >> mail # dev >> VOTE: HDFS-347 merge


Copy link to this message
-
Re: VOTE: HDFS-347 merge
On Wed, Feb 20, 2013 at 3:08 PM, Tsz Wo Sze <[EMAIL PROTECTED]> wrote:
> The reason to keep it around is that the HDFS-347 only support Unix but not
> other OS.

Given that this is an optimization, and we have a ton of optimizations
which don't yet run on Windows, I don't think that should be
considered. Additionally, the Windows support has not yet been merged,
nor is it in any release, so this isn't a regression.

I would be happy to review an addition to the HDFS-347 branch which
addresses this issue. But I don't think we should be maintaining two
codepaths for the sake of an optimization on a platform which is not
yet officially supported on trunk, especially when the old code path
is _insecure_ and thus unusable in most environments.

Todd

>
> ________________________________
> From: Todd Lipcon <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]; Tsz Wo Sze <[EMAIL PROTECTED]>
> Sent: Wednesday, February 20, 2013 3:06 PM
>
> Subject: Re: VOTE: HDFS-347 merge
>
> On Wed, Feb 20, 2013 at 3:01 PM, Tsz Wo Sze <[EMAIL PROTECTED]> wrote:
>> Also, the patch seems to have removed the existing short-circuit read
>> feature (HDFS-2246).  It is an incompatible change.  I think the patch is
>> farther away from being ready and I would keep my -1.
>
> The existing short circuit feature is insecure and was always
> considered a stop-gap solution. If you read the history of that
> feature, you can find comments like
> https://issues.apache.org/jira/browse/HDFS-4476 where I pointed out
> that it's only a stop-gap solution and the only reason I didn't veto
> is that folks agreed to later replace it with the proper solution
> (HDFS-347).
>
> Given that the API is the same, and this is an implementation detail,
> it is not incompatible. There is no reason to keep the old
> implementation around: it is both slower and unusable in the vast
> majority of clusters, where the data directories are owned by an HDFS
> user, and users of the cluster run under other unix credentials.
>
> -Todd
> --
> Todd Lipcon
> Software Engineer, Cloudera
>
>

--
Todd Lipcon
Software Engineer, Cloudera
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB