Mailing-List: contact dev-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@hbase.apache.org
Received-SPF: pass (athena.apache.org: domain of varun@pinterest.com
 designates 209.85.219.46 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CALte62zYowKy+XWwutKdQ9i_RJY59s4YpLKpQ4U-oruza+YtOg@mail.gmail.com>
References: 
 <CAKxWWm2eSRbM+NPVK+cjTihh1f9tavHV2C+AfJB0HTfhG7_xEg@mail.gmail.com>
	<CALte62zYowKy+XWwutKdQ9i_RJY59s4YpLKpQ4U-oruza+YtOg@mail.gmail.com>
Date: Fri, 5 Jul 2013 17:21:54 -0700
Message-ID: 
 <CAKxWWm2mSGQ0aZAwHiVrWSJTpc=mjTJjj07ffV48Y9LwM8xOaA@mail.gmail.com>
Subject: Re: Puzzling behaviour with HBase checksums
From: Varun Sharma <varun@pinterest.com>
To: "dev@hbase.apache.org" <dev@hbase.apache.org>
Content-Type: multipart/alternative; boundary=089e0115f34e737d1d04e0cccc64

--089e0115f34e737d1d04e0cccc64
Content-Type: text/plain; charset=ISO-8859-1

I just set this value in hbase-site.xml but still the 7 byte reads and
lseek(s) persist.


On Fri, Jul 5, 2013 at 4:22 PM, Ted Yu <yuzhihong@gmail.com> wrote:

> What value did you set for dfs.client.read.shortcircuit.skip.checksum ?
>
> Cheers
>
> On Fri, Jul 5, 2013 at 2:55 PM, Varun Sharma <varun@pinterest.com> wrote:
>
> > Hi,
> >
> > We are running hbase with hbase.regionserver.checksum.verify set to true.
> > But we are seeing an equal # of seeks for .meta files on HDFS and data
> > blocks. This is rather puzzling and I dont know if its broken. The hbase
> > jar is compiled against 2.0.3-alpha and this behaviour occurs for both
> > 0.94.3 and 0.94.7. Shortcircuit local reads is enabled is working well
> > since only the region server is accessing the disk.
> >
> > We run an strace limited to lseek calls and get the following:
> >
> > 28162 lseek(*668*, 0, SEEK_SET)           = 0
> > 28162 lseek(*635*, 57479463, SEEK_SET)    = 57479463
> > 28162 lseek(*2255*, 0, SEEK_SET)          = 0
> > 28162 lseek(*1938*, 29285843, SEEK_SET)   = 29285843
> >
> > Then we use lsof to find the underlying files and match them against the
> > corresponding file decriptors...
> >
> > java    27947 hbase * 668u *  REG             202,32   1048583 36176608
> >
> >
> /data/xvdc/hadoop/dfs/data/current/BP-1854623640-10.158.62.78-1363075060974/current/finalized/subdir54/
> > *blk_5081211948968918615_597521.meta*
> > *
> > *
> > java    27947 hbase  *635u*      REG             202,32 134217728
> 36176607
> >
> >
> /data/xvdc/hadoop/dfs/data/current/BP-1854623640-10.158.62.78-1363075060974/current/finalized/subdir54/
> > *blk_5081211948968918615*
> > *
> > *
> > java    27947 hbase *2255u*   REG             202,16    802375 32768850
> >
> >
> /mnt/hadoop/dfs/data/current/BP-1854623640-10.158.62.78-1363075060974/current/finalized/subdir40/
> > *blk_2670783290218647110_614641.meta*
> > *
> > *
> > java    27947 hbase *1938u*   REG             202,16 102702747 32768849
> >
> >
> /mnt/hadoop/dfs/data/current/BP-1854623640-10.158.62.78-1363075060974/current/finalized/subdir40/
> > *blk_2670783290218647110*
> >
> > The pattern in strace is pretty clear - first the .meta is read and then
> > the block is accessed. I am wondering if there are other places apart
> from
> > the checksum where the .meta file for the HDFS block is being accessed or
> > if the checksum stuff is simply broken ? It seems we are accessing 7 byte
> > values in these .meta files from more strace output. Is there a way I can
> > find out if the checksums were actually written out to HFiles in the
> first
> > place ?
> >
> > Thanks
> > Varun
> >
>

--089e0115f34e737d1d04e0cccc64--