Return-Path: X-Original-To: apmail-hadoop-mapreduce-user-archive@minotaur.apache.org Delivered-To: apmail-hadoop-mapreduce-user-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id D66A6E872 for ; Wed, 28 Nov 2012 16:38:52 +0000 (UTC) Received: (qmail 59132 invoked by uid 500); 28 Nov 2012 16:38:48 -0000 Delivered-To: apmail-hadoop-mapreduce-user-archive@hadoop.apache.org Received: (qmail 59033 invoked by uid 500); 28 Nov 2012 16:38:48 -0000 Mailing-List: contact user-help@hadoop.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@hadoop.apache.org Delivered-To: mailing list user@hadoop.apache.org Received: (qmail 59018 invoked by uid 99); 28 Nov 2012 16:38:48 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 28 Nov 2012 16:38:48 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of harsh@cloudera.com designates 209.85.223.176 as permitted sender) Received: from [209.85.223.176] (HELO mail-ie0-f176.google.com) (209.85.223.176) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 28 Nov 2012 16:38:43 +0000 Received: by mail-ie0-f176.google.com with SMTP id 13so15758735iea.35 for ; Wed, 28 Nov 2012 08:38:23 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:x-gm-message-state; bh=FoVJF2IUnZghDx4JrHG/d2jyzGOa195O7I5adkpGEEk=; b=Yv6jUy8XzA/8b76moVmX5L/u7oACU+EJski2gO/Pn0CUO9Q+D5AnIn2oyzqHrzIWaG gUdA+XiN/mRV8yoYB0SNCA8rCLDfkCVTIM0AAPvu7K03tZUrbAEig2yrn54SzpKxnPmv P9Neky/vgMYmih00/ONSYMgXCrsAETw5eHWpEt6c8JDlq5oymhIYbPws5W0oN8w/vTpj JIra10D4V83zqnU0Z5+fi21WzA1wxtK4vBpdTu5gSw3oSINa1BUy6jIM85jU6u8WSRYy rNdfnOKypPxHF06hCPDGAgJAjkrvPgvsY5pHfrL2V4eYYSZ2CyznDgp0FrnRpSMqSRu/ KGnQ== Received: by 10.50.153.137 with SMTP id vg9mr22692187igb.40.1354120703071; Wed, 28 Nov 2012 08:38:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.6.129 with HTTP; Wed, 28 Nov 2012 08:37:58 -0800 (PST) In-Reply-To: References: From: Harsh J Date: Wed, 28 Nov 2012 22:07:58 +0530 Message-ID: Subject: Re: Replacing a hard drive on a slave To: "" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmpFeYCxJHKx4UpVFG8TCPTHH+XPEDUOqnUzSQbfiaObacH+M9qS+RDmHJIB0Y5XbUhkf9f X-Virus-Checked: Checked by ClamAV on apache.org When added back, with blocks retained, the NN would detect that the affected files have over-replicated conditions, and will suitably delete any excess replicas while still adhering to the block placement policy (for rack-aware clusters), but not necessarily everything from the re-added DN will be erased. This is an automatic process and should not worry you in any way, as an operator. On Wed, Nov 28, 2012 at 8:52 PM, Mark Kerzner wrote: > What happens if I stop the datanode, miss the 10 min 30 seconds deadline, > and restart the datanode say 30 minutes later? Will Hadoop re-use the data > on this datanode, balancing it with HDFS? What happens to those blocks that > correspond to file that have been updated meanwhile? > > Mark > > On Wed, Nov 28, 2012 at 6:51 AM, Stephen Fritz > wrote: >> >> HDFS will not start re-replicating blocks from a dead DN for 10 minutes 30 >> seconds by default. >> >> Right now there isn't a good way to replace a disk out from under a >> running datanode, so the best way is: >> - Stop the DN >> - Replace the disk >> - Restart the DN >> >> >> >> >> On Wed, Nov 28, 2012 at 9:14 AM, Mark Kerzner >> wrote: >>> >>> Hi, >>> >>> can I remove one hard drive from a slave but tell Hadoop not to replicate >>> missing blocks for a few minutes, because I will return it back? Or will >>> this not work at all, and will Hadoop continue replicating, since I removed >>> blocks, even for a short time? >>> >>> Thank you. Sincerely, >>> Mark >> >> > -- Harsh J