Return-Path: 
 <hdfs-issues-return-11806-apmail-hadoop-hdfs-issues-archive=hadoop.apache.org@hadoop.apache.org>
Delivered-To: apmail-hadoop-hdfs-issues-archive@minotaur.apache.org
Received: (qmail 68803 invoked from network); 3 Sep 2010 21:20:55 -0000
Received: from unknown (HELO mail.apache.org) (140.211.11.3)
  by 140.211.11.9 with SMTP; 3 Sep 2010 21:20:55 -0000
Received: (qmail 96885 invoked by uid 500); 3 Sep 2010 21:20:55 -0000
Delivered-To: apmail-hadoop-hdfs-issues-archive@hadoop.apache.org
Received: (qmail 96825 invoked by uid 500); 3 Sep 2010 21:20:54 -0000
Mailing-List: contact hdfs-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:hdfs-issues-help@hadoop.apache.org>
List-Unsubscribe: <mailto:hdfs-issues-unsubscribe@hadoop.apache.org>
List-Post: <mailto:hdfs-issues@hadoop.apache.org>
List-Id: <hdfs-issues.hadoop.apache.org>
Reply-To: hdfs-issues@hadoop.apache.org
Delivered-To: mailing list hdfs-issues@hadoop.apache.org
Received: (qmail 96816 invoked by uid 99); 3 Sep 2010 21:20:54 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 03 Sep 2010 21:20:54 +0000
X-ASF-Spam-Status: No, hits=-2000.0 required=10.0
	tests=ALL_TRUSTED
X-Spam-Check-By: apache.org
Received: from [140.211.11.22] (HELO thor.apache.org) (140.211.11.22)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 03 Sep 2010 21:20:54 +0000
Received: from thor (localhost [127.0.0.1])
	by thor.apache.org (8.13.8+Sun/8.13.8) with ESMTP id o83LKYlW025731
	for <hdfs-issues@hadoop.apache.org>; Fri, 3 Sep 2010 21:20:34 GMT
Message-ID: <25040656.20411283548834116.JavaMail.jira@thor>
Date: Fri, 3 Sep 2010 17:20:34 -0400 (EDT)
From: "Jakob Homan (JIRA)" <jira@apache.org>
To: hdfs-issues@hadoop.apache.org
Subject: [jira] Commented: (HDFS-1353) Remove most of getBlockLocation
 optimization
In-Reply-To: <16858593.547681282696639076.JavaMail.jira@thor>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394


    [ https://issues.apache.org/jira/browse/HDFS-1353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12906101#action_12906101 ] 

Jakob Homan commented on HDFS-1353:
-----------------------------------

bq. In BlockTokenIdentifier constructor, should we check for non-zero blockId? Earlier we checked for non-null blockIds array. 
The blockID is a random number, so it might be 0, so we don't need to check that.  Thanks.

> Remove most of getBlockLocation optimization
> --------------------------------------------
>
>                 Key: HDFS-1353
>                 URL: https://issues.apache.org/jira/browse/HDFS-1353
>             Project: Hadoop HDFS
>          Issue Type: Improvement
>          Components: name-node
>    Affects Versions: 0.21.0
>            Reporter: Jakob Homan
>            Assignee: Jakob Homan
>             Fix For: 0.21.1, 0.22.0
>
>         Attachments: Benchmarking results.xlsx, HDFS-1353-y20.patch, HDFS-1353.patch
>
>
> <This description is not valid. See comment.>
> HDFS-1081 optimized the number of block access tokens (BATs) created in a single call to getBlockLocations, as this is an expensive operation.  However, that JIRA put off another optimization which was then made possible, which is to just send a single block access token across the wire (and maintain a single BAT on the client side).  This JIRA is for implementing that optimization.  Since a single BAT is generated for all the blocks, we just write that single BAT to the wire, rather than writing n BATs for n blocks, as is currently done.  This turns out to be a useful optimization for files with very large numbers of blocks, as the new lone BAT is much larger than was a BAT previously.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.