Return-Path: X-Original-To: apmail-accumulo-user-archive@www.apache.org Delivered-To: apmail-accumulo-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 93D3C18BDD for ; Mon, 17 Aug 2015 20:12:58 +0000 (UTC) Received: (qmail 88538 invoked by uid 500); 17 Aug 2015 20:12:00 -0000 Delivered-To: apmail-accumulo-user-archive@accumulo.apache.org Received: (qmail 88486 invoked by uid 500); 17 Aug 2015 20:11:59 -0000 Mailing-List: contact user-help@accumulo.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@accumulo.apache.org Delivered-To: mailing list user@accumulo.apache.org Received: (qmail 88476 invoked by uid 99); 17 Aug 2015 20:11:59 -0000 Received: from Unknown (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 17 Aug 2015 20:11:59 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org) with ESMTP id 7A044DE2F8 for ; Mon, 17 Aug 2015 20:11:59 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 2.323 X-Spam-Level: ** X-Spam-Status: No, score=2.323 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=3, RP_MATCHES_RCVD=-0.577, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=disabled Authentication-Results: spamd1-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net Received: from mx1-eu-west.apache.org ([10.40.0.8]) by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id kUHntoddviy7 for ; Mon, 17 Aug 2015 20:11:47 +0000 (UTC) Received: from resqmta-ch2-08v.sys.comcast.net (resqmta-ch2-08v.sys.comcast.net [69.252.207.40]) by mx1-eu-west.apache.org (ASF Mail Server at mx1-eu-west.apache.org) with ESMTPS id 8378920D31 for ; Mon, 17 Aug 2015 20:11:46 +0000 (UTC) Received: from resomta-ch2-01v.sys.comcast.net ([69.252.207.97]) by resqmta-ch2-08v.sys.comcast.net with comcast id 5wBW1r00126dK1R01wBf8X; Mon, 17 Aug 2015 20:11:39 +0000 Received: from resmail-ch2-129v.sys.comcast.net ([162.150.48.163]) by resomta-ch2-01v.sys.comcast.net with comcast id 5wBe1r00Z3XFKay01wBekp; Mon, 17 Aug 2015 20:11:38 +0000 Date: Mon, 17 Aug 2015 20:11:38 +0000 (UTC) From: dlmarion@comcast.net To: user@accumulo.apache.org Message-ID: <710453995.3475721.1439842298809.JavaMail.zimbra@comcast.net> In-Reply-To: References: Subject: Re: Accumulo GC and Hadoop trash settings MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3475720_222432981.1439842298808" X-Originating-IP: [::ffff:144.51.241.32] X-Mailer: Zimbra 8.0.7_GA_6031 (ZimbraWebClient - FF38 (Linux)/8.0.7_GA_6031) Thread-Topic: Accumulo GC and Hadoop trash settings Thread-Index: eST3HmyhIMel9IMgV4k7dwTVvmf4sw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1439842299; bh=KRVE35w9TnWkAbQxuc7lr/aHghlRJWqTEjLBccySwhM=; h=Received:Received:Date:From:To:Message-ID:Subject:MIME-Version: Content-Type; b=CNId7mhUxPrFGKojv6eWdUqeeYNN5/qpB3NHFqyrCs6DCX1wcZXrU5J8m8Y4Wf7mG vzHNwyit12Mpwr66cH4Gvj1uSLXasQXVc0jeKEhrGyv0YGIy2itrdyoPCB7+og+yCM uRuzDE6u1i4euctyHBD/PNSENXOLv9i0b/px63/b3Yuj2gLJaQjLR/cWtgrbU4ifk0 5nYj7O4uPsvZrH5YBG6n0SlsNpOfx2N4Do3M8r6LfR1jOsPoybEDvUhU0pVK5pn0ej xCbBTN6OwV3IwfuYXbQXTYa8ijVTlnSAfeOdTB6CGMgV8qGdV8oMtrWjQ/4EAhFfOG xO4Ocr6jgFe/g== ------=_Part_3475720_222432981.1439842298808 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit It's not temporary files, it's any file that has been compacted away. If you keep files around longer than { dfs.namenode.checkpoint.period}, then you have a chance to recover in case your most recent checkpoint is corrupt. ----- Original Message ----- From: "James Hughes" To: user@accumulo.apache.org Sent: Monday, August 17, 2015 3:57:57 PM Subject: Accumulo GC and Hadoop trash settings Hi all, >From reading about the Accumulo GC, it sounds like temporary files are routinely deleted during GC cycles. In a small testing environment, I've the HDFS Accumulo user's .Trash folder have 10s of gigabytes of data. Is there any reason that the default value for gc.trash.ignore is false? Is there any downside to deleting GC'ed files completely? Thanks in advance, Jim http://accumulo.apache.org/1.6/accumulo_user_manual.html#_gc_trash_ignore ------=_Part_3475720_222432981.1439842298808 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

 It's not temporary files, it's any file that = has been compacted away. If you keep files around longer than {dfs.namenode.che= ckpoint.period}, then you have a chance to recover in case your most recent= checkpoint is corrupt.

From: "James H= ughes" <jnh5y@virginia.edu>
To: user@accumulo.apache.orgSent: Monday, August 17, 2015 3:57:57 PM
Subject: Accumul= o GC and Hadoop trash settings

Hi all,
From reading about the Accumulo GC, it sounds like tempor= ary files are routinely deleted during GC cycles.  In a small testing = environment, I've the HDFS Accumulo user's .Trash folder have 10s of gigaby= tes of data.

Is there any reason that the default value for g= c.trash.ignore is false?  Is there any downside to deleting GC'ed file= s completely?

Thanks in advance,

------=_Part_3475720_222432981.1439842298808--