This is an automated email from the git hooks/post-receive script.
sebastic pushed a change to tag debian/1.11.2-1.exp2
in repository gdal-grass.
at 4b6cde9 (commit)
No new revisions were added by this update.
--
Alioth's /usr/local/bin/git-commit-notice on
/srv/git.debian.org/git/pkg-grass/gdal-grass.git
_______________________________________________
Pkg-grass-devel mailing list
[email protected]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-grass-devel
From hdfs-issues-return-113448-archive=mail-archive....@hadoop.apache.org Wed
Mar 18 14:29:49 2015
Return-path:
<hdfs-issues-return-113448-archive=mail-archive....@hadoop.apache.org>
Envelope-to: [email protected]
Delivery-date: Wed, 18 Mar 2015 14:29:49 -0700
Received: from bolt10b.mxthunder.net ([208.53.48.136])
by mail-archive.com with esmtp (Exim 4.76)
(envelope-from
<hdfs-issues-return-113448-archive=mail-archive....@hadoop.apache.org>)
id 1YYLXA-0008Ml-MM
for [email protected]; Wed, 18 Mar 2015 14:29:48 -0700
Received: by bolt10b.mxthunder.net (Postfix, from userid 12345)
id 3l6kzD0NYnz27lP3; Wed, 18 Mar 2015 14:29:43 -0700 (PDT)
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
by bolt10b.mxthunder.net (Postfix) with SMTP id 3l6kz71Zrvz27lMw
for <[email protected]>; Wed, 18 Mar 2015 14:29:38 -0700 (PDT)
Received: (qmail 61088 invoked by uid 500); 18 Mar 2015 21:29:38 -0000
Mailing-List: contact [email protected]; run by ezmlm
Precedence: bulk
List-Help: <mailto:[email protected]>
List-Unsubscribe: <mailto:[email protected]>
List-Post: <mailto:[email protected]>
List-Id: <hdfs-issues.hadoop.apache.org>
Reply-To: [email protected]
Delivered-To: mailing list [email protected]
Received: (qmail 60832 invoked by uid 99); 18 Mar 2015 21:29:38 -0000
Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28)
by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 18 Mar 2015 21:29:38 +0000
Date: Wed, 18 Mar 2015 21:29:38 +0000 (UTC)
From: "Jing Zhao (JIRA)" <[email protected]>
To: [email protected]
Message-ID: <[email protected]>
In-Reply-To: <[email protected]>
References: <[email protected]>
<JIRA.12782644.1426616393999@arcas>
Subject: [jira] [Comment Edited] (HDFS-7943) Append cannot handle the last
block with length greater than the preferred block size
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394
X-MXTHUNDER-Identifier:
<[email protected]>
X-MXTHUNDER-IP-Rating: 0, 140.211.11.3, Ugly c=0.866291 p=-0.991063 Source
White
X-MXTHUNDER-Scan-Result: 0
X-MXTHUNDER-Rules:
0-0-0-6851-c
X-MXTHUNDER-Clean: Yes
X-MXTHUNDER-Group: OK
[
https://issues.apache.org/jira/browse/HDFS-7943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14367953#comment-14367953
]
Jing Zhao edited comment on HDFS-7943 at 3/18/15 9:29 PM:
----------------------------------------------------------
I have an initial patch fixing the issue following #1. Then I find that more
places have the assumption that the block's size upper limit is the preferred
size. E.g., when conversion between UC block and complete block happens, we
always follow this assumption to update quota usage. Also, when computing
storage usage of a UC file, we use the preferred size as the size of the last
UC block. These places require fixes as well.
Currently I prefer #2 because of its simplicity. Also I think it is good to
have the preferred block size as the upper limit. This upper limit is also kind
of respected by the client while writing data.
What do you think, [~szetszwo]?
was (Author: jingzhao):
I kindly of have an initial patch fixing the issue following #1. Then I find
that more places have the assumption that the block's size upper limit is the
preferred size. E.g., when conversion between UC block and complete block
happens, we always follow this assumption to update quota usage. Also, when
computing storage usage of a UC file, we use the preferred size as the size of
the last UC block. These places require fixes as well.
Currently I prefer #2 because of its simplicity. Also I think it is good to
have the preferred block size as the upper limit. This upper limit is also kind
of respected by the client while writing data.
What do you think, [~szetszwo]?
> Append cannot handle the last block with length greater than the preferred
> block size
> -------------------------------------------------------------------------------------
>
> Key: HDFS-7943
> URL: https://issues.apache.org/jira/browse/HDFS-7943
> Project: Hadoop HDFS
> Issue Type: Bug
> Affects Versions: 2.7.0
> Reporter: Jing Zhao
> Assignee: Jing Zhao
> Priority: Blocker
> Attachments: HDFS-7943.000.patch
>
>
> In HDFS-3689, we remove the restriction from concat that all the source files
> should have the same preferred block size with the target file. This can
> cause a file to contain blocks with size larger than its preferred block size.
> If such block happens to be the last block of a file, and later we append
> data to the file without the {{CreateFlag.NEW_BLOCK}} flag (i.e., appending
> data to the last block), looks like the current client code will keep writing
> to the last block and never allocate a new block.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
