[
https://issues.apache.org/jira/browse/HDFS-2080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13051115#comment-13051115
]
Kihwal Lee commented on HDFS-2080:
----------------------------------
The checksum was worked on previously in HADOOP-6148 and HADOOP-6166. Due to
implicit data copying when crossing JNI boundary, it was reimplemented in JAVA.
This work will solve the problem and get us back to faster native code. I
imagine there are other places we could apply the NIO direct buffer + JNI +
native code combination.
In my experiment, zlib was already capable of doing more than most clients can
ingest. On a system with 2GHz E5335 (Clovertown) processors running CentOS5,
the CRC32 in zlib could do 2.5 GB/s if everything comes from cache (on a 64KB
buffer). So in my opinion, although they look seriously cool, the item number 4
and 5 can wait.
> Speed up DFS read path
> ----------------------
>
> Key: HDFS-2080
> URL: https://issues.apache.org/jira/browse/HDFS-2080
> Project: Hadoop HDFS
> Issue Type: Improvement
> Components: hdfs client
> Affects Versions: 0.23.0
> Reporter: Todd Lipcon
> Assignee: Todd Lipcon
> Fix For: 0.23.0
>
>
> I've developed a series of patches that speeds up the HDFS read path by a
> factor of about 2.5x (~300M/sec to ~800M/sec for localhost reading from
> buffer cache) and also will make it easier to allow for advanced users (eg
> hbase) to skip a buffer copy.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
