Return-Path: Delivered-To: apmail-hadoop-core-user-archive@www.apache.org Received: (qmail 49449 invoked from network); 4 Jun 2008 07:01:46 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 4 Jun 2008 07:01:46 -0000 Received: (qmail 822 invoked by uid 500); 4 Jun 2008 07:01:44 -0000 Delivered-To: apmail-hadoop-core-user-archive@hadoop.apache.org Received: (qmail 730 invoked by uid 500); 4 Jun 2008 07:01:44 -0000 Mailing-List: contact core-user-help@hadoop.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: core-user@hadoop.apache.org Delivered-To: mailing list core-user@hadoop.apache.org Received: (qmail 719 invoked by uid 99); 4 Jun 2008 07:01:44 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 04 Jun 2008 00:01:44 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [64.71.238.252] (HELO outbound.mse16.exchange.ms) (64.71.238.252) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 04 Jun 2008 07:00:55 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C8C610.C4BE971A" Subject: RE: setrep Date: Wed, 4 Jun 2008 02:57:22 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: setrep Thread-Index: AcjGCexg2lxlcj3ZRKCafTW5/g5tLgABlBUK References: <82450.71496.qm@web53612.mail.re2.yahoo.com> From: "Haijun Cao" To: X-Virus-Checked: Checked by ClamAV on apache.org ------_=_NextPart_001_01C8C610.C4BE971A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Lohit, Thanks for the explanation. If that's the case, then it is not slower = than expected. =20 Haijun -----Original Message----- From: lohit [mailto:lohit_bv@yahoo.com] Sent: Wed 6/4/2008 2:11 AM To: core-user@hadoop.apache.org Subject: Re: setrep =20 >It seems that setrep won't force replication change to the specified = number immediately, it changed really slowly. just wondering if this is = the expected behavior? what's the rational for this behavior? is there = way to speed it up?=20 Yes, it wont force replication to be instant. Once you increase the = replication factor of a file, namenode adds it to neededReplication = list. Namenode has a thread running which periodically scans this list = and chooses a set of blocks which are under replicated and request the = datanodes to replicate them. This interval is configured using = dfs.replication.interval config variable. Interval = dfs.replication.interval is in seconds. The list of neededReplication also maintains a priority policy, where in = blocks with only one copy would be replicated first.=20 If you do not have lot of underReplicated blocks, this should happen = pretty fast. Are you seeing very long delays?=20 Thanks, Lohit ------_=_NextPart_001_01C8C610.C4BE971A--