hadoop-hdfs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jitendra Pandey <jiten...@hortonworks.com>
Subject Re: [VOTE] Merge HDFS-6581 to trunk - Writing to replicas in memory.
Date Wed, 24 Sep 2014 18:29:40 GMT
I would consider following as blockers to merge to trunk:

a) Any bugs that makes the feature unusable or cause instability or cause
any regression.
b) Any bad design choices that add technical debt.
c) Any missing functionality, that makes the feature useless or difficult
to use for its intended use cases.

Otherwise, we keep adding optimizations and improvements even after merging
to trunk. In fact we often discover bugs after merge to trunk and then
diligently fix them.

I will take a stab at Colin's concerns and state my view about whether it
should block the merge or not.

* Checksum skipping on read and write from lazy persisted replicas.
  This is a performance optimization. The numbers posted on the jira show
significant performance improvement even without this optimization. I think
we can do the merge and add this optimization in trunk.

* Allowing mmaped reads from the lazy persisted data.
   I don't think the feature prevents mmapped reads from lazy persisted
data. So there shouldn't be a regression.

* Any eviction strategy other than LRU.
   LRU is a decent strategy for many use cases. And I think it will be hard
to find a single strategy that fits all scenarios. Therefore a plugin
approach with LRU as default, seems like a decent approach.

* Integration with cache pool limits (how do HDFS-4949 and lazy
persist replicas share memory)?
   Arpit dealt with this in his earlier comment.

* Eviction from RAM disk via truncation (HDFS-6918)
    This again seems to be a nice optimization which we can do after the

* Metrics
    These are nice to haves, and we do keep adding metrics to the system as
and when we feel the need. This doesn't affect the basic
functionality/design or usefulness of the feature.

* System testing to find out how useful this is, and what the best
eviction strategy is.
    We do need to make sure that the system is sufficiently tested. I will
let Arpit comment on this.

NOTICE: This message is intended for the use of the individual or entity to 
which it is addressed and may contain information that is confidential, 
privileged and exempt from disclosure under applicable law. If the reader 
of this message is not the intended recipient, you are hereby notified that 
any printing, copying, dissemination, distribution, disclosure or 
forwarding of this communication is strictly prohibited. If you have 
received this communication in error, please contact the sender immediately 
and delete it from your system. Thank You.

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