Return-Path: Delivered-To: apmail-hadoop-hdfs-issues-archive@minotaur.apache.org Received: (qmail 11703 invoked from network); 26 Oct 2009 05:54:23 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 26 Oct 2009 05:54:23 -0000 Received: (qmail 93905 invoked by uid 500); 26 Oct 2009 05:54:23 -0000 Delivered-To: apmail-hadoop-hdfs-issues-archive@hadoop.apache.org Received: (qmail 93835 invoked by uid 500); 26 Oct 2009 05:54:23 -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 93820 invoked by uid 99); 26 Oct 2009 05:54:23 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 26 Oct 2009 05:54:23 +0000 X-ASF-Spam-Status: No, hits=-10.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI 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; Mon, 26 Oct 2009 05:54:20 +0000 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id 91FE3234C045 for ; Sun, 25 Oct 2009 22:54:00 -0700 (PDT) Message-ID: <803003878.1256536440573.JavaMail.jira@brutus> Date: Mon, 26 Oct 2009 05:54:00 +0000 (UTC) From: "dhruba borthakur (JIRA)" To: hdfs-issues@hadoop.apache.org Subject: [jira] Commented: (HDFS-729) fsck option to list only corrupted files In-Reply-To: <526750676.1256282639364.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/HDFS-729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12769902#action_12769902 ] dhruba borthakur commented on HDFS-729: --------------------------------------- > Is this a regular fsck with less output? That might still be prohibitively long and expensive for regular poll Yes, at this point, I am visualizing it as a regular fsck with less output. The problem with making this a new Namenode RPC is that this RPC would have an upper limit on the number of corrupted files that can be returned via one single invocation of the RPC. This kind-of- reduces the elegance of such an API. The alternative is to make this new RPC retrieve a max number of corrupted files together with a cookie that can be used in the next invocation of the RPC to retrieve the remaining set of corrupted files (similar to readdir). If we use a regular fsck, it does not lock the NN for an extended period of time, neither does it have a problem if the number of files to be retrieved is huge. > fsck option to list only corrupted files > ---------------------------------------- > > Key: HDFS-729 > URL: https://issues.apache.org/jira/browse/HDFS-729 > Project: Hadoop HDFS > Issue Type: Improvement > Reporter: dhruba borthakur > Assignee: dhruba borthakur > > An option to fsck to list only corrupted files will be very helpful for frequent monitoring. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.