hadoop-hdfs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Suresh Srinivas <sur...@hortonworks.com>
Subject Re: VOTE: HDFS-347 merge
Date Wed, 20 Feb 2013 23:31:27 GMT
On Wed, Feb 20, 2013 at 3:13 PM, Todd Lipcon <todd@cloudera.com> wrote:

> On Wed, Feb 20, 2013 at 3:08 PM, Tsz Wo Sze <szetszwo@yahoo.com> 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.

This is a critical functionality for HBase peformance and an optimization
we consider
very important to have.

> 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.

I have to disagree. No where in the jira or the design it is explicitly
stated that
the old short circuit functionality is being removed. My assumption has been
that it will not be removed.

As regards "officially supported", we have been doing
windows development for
more than a year. In fact branch-1-win is being used by a lot users. Given
merging it to branch-1 requires first making it available in trunk, we have
been doing
a lot of work in branch-trunk-win. It is almost ready to be merged as well.

I am -1 on removing existing short circuit until an alternative short
circuit similar
to HDFS-347 on all the platforms.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message