Return-Path: X-Original-To: apmail-hadoop-hdfs-issues-archive@minotaur.apache.org Delivered-To: apmail-hadoop-hdfs-issues-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 350599874 for ; Thu, 22 Mar 2012 20:34:45 +0000 (UTC) Received: (qmail 55015 invoked by uid 500); 22 Mar 2012 20:34:45 -0000 Delivered-To: apmail-hadoop-hdfs-issues-archive@hadoop.apache.org Received: (qmail 54974 invoked by uid 500); 22 Mar 2012 20:34:45 -0000 Mailing-List: contact hdfs-issues-help@hadoop.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: hdfs-issues@hadoop.apache.org Delivered-To: mailing list hdfs-issues@hadoop.apache.org Received: (qmail 54965 invoked by uid 99); 22 Mar 2012 20:34:45 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 22 Mar 2012 20:34:45 +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; Thu, 22 Mar 2012 20:34:43 +0000 Received: from hel.zones.apache.org (hel.zones.apache.org [140.211.11.116]) by hel.zones.apache.org (Postfix) with ESMTP id E0B2E340C8F for ; Thu, 22 Mar 2012 20:34:23 +0000 (UTC) Date: Thu, 22 Mar 2012 20:34:23 +0000 (UTC) From: "Milind Bhandarkar (Commented) (JIRA)" To: hdfs-issues@hadoop.apache.org Message-ID: <570619806.4431.1332448463922.JavaMail.tomcat@hel.zones.apache.org> In-Reply-To: <2049515590.23016.1331873625982.JavaMail.tomcat@hel.zones.apache.org> Subject: [jira] [Commented] (HDFS-3107) HDFS truncate 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/HDFS-3107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13235996#comment-13235996 ] Milind Bhandarkar commented on HDFS-3107: ----------------------------------------- Thought a little more about this. The namenode RPC should have length as exactly a multiple of blocksize, otherwise it should throw exception. (so, option 1 in my comment above.) And concatFile could be null, so that case where files need to be truncated to exactly block boundary (option 1 in Nicholas's comment) can be trivially supported. > HDFS truncate > ------------- > > Key: HDFS-3107 > URL: https://issues.apache.org/jira/browse/HDFS-3107 > Project: Hadoop HDFS > Issue Type: New Feature > Components: data-node, name-node > Reporter: Lei Chang > Attachments: HDFS_truncate_semantics_Mar15.pdf, HDFS_truncate_semantics_Mar21.pdf > > Original Estimate: 1,344h > Remaining Estimate: 1,344h > > Systems with transaction support often need to undo changes made to the underlying storage when a transaction is aborted. Currently HDFS does not support truncate (a standard Posix operation) which is a reverse operation of append, which makes upper layer applications use ugly workarounds (such as keeping track of the discarded byte range per file in a separate metadata store, and periodically running a vacuum process to rewrite compacted files) to overcome this limitation of HDFS. -- 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