Return-Path: X-Original-To: apmail-hbase-issues-archive@www.apache.org Delivered-To: apmail-hbase-issues-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 44A069B06 for ; Wed, 22 Feb 2012 19:20:15 +0000 (UTC) Received: (qmail 89702 invoked by uid 500); 22 Feb 2012 19:20:15 -0000 Delivered-To: apmail-hbase-issues-archive@hbase.apache.org Received: (qmail 89646 invoked by uid 500); 22 Feb 2012 19:20:15 -0000 Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list issues@hbase.apache.org Received: (qmail 89581 invoked by uid 99); 22 Feb 2012 19:20:14 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 22 Feb 2012 19:20:14 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=5.0 tests=ALL_TRUSTED,T_RP_MATCHES_RCVD X-Spam-Check-By: apache.org Received: from [140.211.11.116] (HELO hel.zones.apache.org) (140.211.11.116) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 22 Feb 2012 19:20:12 +0000 Received: from hel.zones.apache.org (hel.zones.apache.org [140.211.11.116]) by hel.zones.apache.org (Postfix) with ESMTP id A50563348FC for ; Wed, 22 Feb 2012 19:19:51 +0000 (UTC) Date: Wed, 22 Feb 2012 19:19:51 +0000 (UTC) From: "Phabricator (Commented) (JIRA)" To: issues@hbase.apache.org Message-ID: <206021019.5641.1329938391677.JavaMail.tomcat@hel.zones.apache.org> In-Reply-To: <155647929.29704.1324361611230.JavaMail.tomcat@hel.zones.apache.org> Subject: [jira] [Commented] (HBASE-5074) support checksums in HBase block cache MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/HBASE-5074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13213884#comment-13213884 ] Phabricator commented on HBASE-5074: ------------------------------------ stack has commented on the revision "[jira] [HBASE-5074] Support checksums in HBase block cache". Answering Dhruba. INLINE COMMENTS src/main/java/org/apache/hadoop/hbase/fs/HFileSystem.java:115 Seems like we could have better names for these methods, ones that give more of a clue as to what they are about. getBackingFS, getNoChecksumFS? Maybe you are keepign them generic like this because you will be back in this area again soon doing another beautiful speedup on top of this checksumming fix (When we going to do read-ahead? Would that speed scanning?) src/main/java/org/apache/hadoop/hbase/io/hfile/AbstractHFileReader.java:44 ok. np. src/main/java/org/apache/hadoop/hbase/io/hfile/AbstractHFileReader.java:49 Ok. So, two readers. Our file count is going to go up? We should release note this as side effect of enabling this feature (previous you may have been well below xceivers limit but now you could go over the top?) I didn't notice this was going on. Need to foreground it I'd say. src/main/java/org/apache/hadoop/hbase/io/hfile/ChecksumUtil.java:84 I figured. Its fine as is. REVISION DETAIL https://reviews.facebook.net/D1521 > support checksums in HBase block cache > -------------------------------------- > > Key: HBASE-5074 > URL: https://issues.apache.org/jira/browse/HBASE-5074 > Project: HBase > Issue Type: Improvement > Components: regionserver > Reporter: dhruba borthakur > Assignee: dhruba borthakur > Attachments: D1521.1.patch, D1521.1.patch, D1521.2.patch, D1521.2.patch, D1521.3.patch, D1521.3.patch, D1521.4.patch, D1521.4.patch, D1521.5.patch, D1521.5.patch, D1521.6.patch, D1521.6.patch, D1521.7.patch, D1521.7.patch > > > The current implementation of HDFS stores the data in one block file and the metadata(checksum) in another block file. This means that every read into the HBase block cache actually consumes two disk iops, one to the datafile and one to the checksum file. This is a major problem for scaling HBase, because HBase is usually bottlenecked on the number of random disk iops that the storage-hardware offers. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira