hadoop-hdfs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eli Collins <...@cloudera.com>
Subject Re: [DISCUSS] Remove append?
Date Wed, 21 Mar 2012 21:08:21 GMT
On Wed, Mar 21, 2012 at 1:57 PM, Sanjay Radia <sanjay@hortonworks.com> wrote:
> On Tue, Mar 20, 2012 at 5:37 PM, Eli Collins <eli@cloudera.com> wrote:
>> Append introduces non-trivial design and code complexity, which is not
>> worth the cost if we don't have real users.
> The bulk of the complexity of HDFS-265 ("the new Append") was around
> Hflush, concurrent readers, the pipeline etc. The code and complexity  for
> appending to previously closed file was not that large.

And we'd still leverage that work.  Which is not to say that append
isn't complicated. There were a fair number of append bugs that were
found in branch-20-append that we think are present in the new append
implementation (not sure if there are jiras for all of them).

Also, append + truncate removes the current invariant that we maintain
eg around visible length. So append opens the doors for lots of
additional complexity. We could decide to keep append but not add
truncate but I suspect that will be hard because once you open up the
doors to a lot of new use cases it's hard to close them.  The larger
issue is how simple we'd like to keep HDFS, how many use cases we'd
like to grow it to.

>> Removing append means we
>> have the property that HDFS blocks, when finalized, are immutable.
>> This significantly simplifies the design and code, which significantly
>> simplifies the implementation of other features like snapshots,
>> HDFS-level caching, dedupe, etc.
> While Snapshots  are challenging with Append, it is solvable - the snapshot
> needs to remember the length of the file. (We have a working prototype - we
> will posting the design and the code soon).

Will check it out. When I read "Snapshots in Hadoop Distributed File
System" it looked like the bulk of the complexity was due to the
protocol for append:

> I agree that the notion of an immutable file is useful since it lets the
> system and tools optimize certain things.  A xerox-parc file system in the
> 80s had this feature that the system exploited. I would support adding the
> notion of an immutable file to Hadoop.

Good point, we could leverage this property on a per-file, rather than
per-filesystem basis.


View raw message