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
Pkg-grass-devel@lists.alioth.debian.org
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: arch...@mail-archive.com
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 arch...@mail-archive.com; 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 <arch...@mail-archive.com>; 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 hdfs-issues-h...@hadoop.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:hdfs-issues-h...@hadoop.apache.org>
List-Unsubscribe: <mailto:hdfs-issues-unsubscr...@hadoop.apache.org>
List-Post: <mailto:hdfs-iss...@hadoop.apache.org>
List-Id: <hdfs-issues.hadoop.apache.org>
Reply-To: hdfs-iss...@hadoop.apache.org
Delivered-To: mailing list hdfs-iss...@hadoop.apache.org
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)" <j...@apache.org>
To: hdfs-iss...@hadoop.apache.org
Message-ID: <jira.12782644.1426616393000.136118.1426714178...@atlassian.jira>
In-Reply-To: <jira.12782644.1426616393...@atlassian.jira>
References: <jira.12782644.1426616393...@atlassian.jira>
<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:
<jira.12782644.1426616393000.136118.1426714178...@atlassian.jira>
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)
