[
https://issues.apache.org/jira/browse/HDFS-4960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13703810#comment-13703810
]
Varun Sharma commented on HDFS-4960:
------------------------------------
Actually, I am currently failing to max out the SSD(s) and I am essentially
looking out for things that hog CPU resources or could be time sinks. Even with
this patch, i fail to max out the hardware.
I will try to run an isolated test perhaps with just HDFS random seeks on the
drives (no HBase). I agree that we need to have a test showing that this is
really better. Currently, I doubt that it will be easy because it seems that a
bunch of other paths which are hogging cpu resources.
As for SSDs, seeks do matter if you are looking max them out or utilize them
well enough. They obviously dont matter if you are looking at doing < 10K iops.
> Unnecessary .meta seeks even when skip checksum is true
> -------------------------------------------------------
>
> Key: HDFS-4960
> URL: https://issues.apache.org/jira/browse/HDFS-4960
> Project: Hadoop HDFS
> Issue Type: Bug
> Affects Versions: 3.0.0, 2.1.0-beta
> Reporter: Varun Sharma
> Assignee: Varun Sharma
> Attachments: 4960-branch2.patch, 4960-trunk.patch
>
>
> While attempting to benchmark an HBase + Hadoop 2.0 setup on SSDs, we found
> unnecessary seeks into .meta files, each seek was a 7 byte read at the head
> of the file - this attempts to validate the version #. Since the client is
> requesting no-checksum, we should not be needing to touch the .meta file at
> all.
> Since the purpose of skip checksum is to also avoid the performance penalty
> of the extra seek, we should not be seeking into .meta if skip checksum is
> true
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
