hadoop-hdfs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aaron T. Myers" <...@cloudera.com>
Subject Re: VOTE: HDFS-347 merge
Date Thu, 21 Feb 2013 01:12:32 GMT
On Wed, Feb 20, 2013 at 4:29 PM, Chris Douglas <cdouglas@apache.org> wrote:

> Given that HDFS-347 is a strictly better approach, once committed,
> there will be ample motivation to add support for other OSes and
> remove HDFS-2246 entirely. Nobody is confused about this. There's
> ample precedent for retaining obscure, clumsy features as a temporary
> stop-gap (e.g., service plugins, opaque blobs of bytes in Tasks,
> configurable combiner semantics). What's the virtue of insisting on
> removing this? Unless there was a lot of follow-on work, HDFS-2246
> doesn't look like a lot of code...

Though it's not a ton of code, I think that having to support a more
complex fallback path (i.e. try the HDFS-347 method, then fall back to
trying the HDFS-2246 method, then fall back to doing normal TCP reads to
the local DN) will make the code quite a bit hairier for little added

How about this proposal for a compromise:

Given that the only substantive concerns with HDFS-347 seem to be about
Windows support for local reads, for now we only merge this branch to
trunk. Support for doing HDFS-2246 style local reads will be removed from
trunk, but retained in branch-2 for now. Only once someone adds support for
doing HDFS-347 style local reads which work on Windows will we consider
merging HDFS-347 to branch-2. This should ensure that there's no feature
regression on branch-2, but also means that we will not need to maintain
the HDFS-2246 code path alongside the HDFS-347 code path indefinitely.

Aaron T. Myers
Software Engineer, Cloudera

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