Return-Path: Delivered-To: apmail-hadoop-hdfs-dev-archive@minotaur.apache.org Received: (qmail 76237 invoked from network); 10 Dec 2009 00:05:43 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 10 Dec 2009 00:05:43 -0000 Received: (qmail 49274 invoked by uid 500); 10 Dec 2009 00:05:43 -0000 Delivered-To: apmail-hadoop-hdfs-dev-archive@hadoop.apache.org Received: (qmail 49178 invoked by uid 500); 10 Dec 2009 00:05:42 -0000 Mailing-List: contact hdfs-dev-help@hadoop.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: hdfs-dev@hadoop.apache.org Delivered-To: mailing list hdfs-dev@hadoop.apache.org Received: (qmail 48857 invoked by uid 99); 10 Dec 2009 00:05:42 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 10 Dec 2009 00:05:42 +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.140] (HELO brutus.apache.org) (140.211.11.140) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 10 Dec 2009 00:05:39 +0000 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id E0047234C4AE for ; Wed, 9 Dec 2009 16:05:18 -0800 (PST) Message-ID: <778840799.1260403518916.JavaMail.jira@brutus> Date: Thu, 10 Dec 2009 00:05:18 +0000 (UTC) From: "Todd Lipcon (JIRA)" To: hdfs-dev@hadoop.apache.org Subject: [jira] Created: (HDFS-821) Garbage collect datanode tmp dirs 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 Garbage collect datanode tmp dirs --------------------------------- Key: HDFS-821 URL: https://issues.apache.org/jira/browse/HDFS-821 Project: Hadoop HDFS Issue Type: Improvement Components: data-node Affects Versions: 0.22.0 Reporter: Todd Lipcon I've seen in practice (and it's been reported on the list) cases where the datanode's tmp dir can become quite full with abandoned blocks. There's an ancient comment from April 07: {code} // REMIND - mjc - eventually we should have a timeout system // in place to clean up block files left by abandoned clients. // We should have some timer in place, so that if a blockfile // is created but non-valid, and has been idle for >48 hours, // we can GC it safely. {code} Well, we can consider ourselves reminded, so let's do it! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.