Mailing-List: contact user-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@hadoop.apache.org
Received-SPF: pass (nike.apache.org: domain of harsh@cloudera.com designates
 209.85.214.176 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAB4PkTwy+ueMn4vzAi-FBdJaPwdDUkRzsUxVThLepWs7g8Gtbg@mail.gmail.com>
References: 
 <CAB4PkTx7q4+xz8wwaEva50RTWqks0yucBP_Gp7UWf6co=tFoig@mail.gmail.com>
 <CAOcnVr2YmGG5PbVFer6WEhAb5YRNY=Az+fpRqTSebB6rtc7BkA@mail.gmail.com>
 <CAB4PkTxt5Rho601j1khAqR7WHidDs0YzguQ5-QmmeZWSM0h3-g@mail.gmail.com>
 <CAL=FoJQfY69vLHsR9XeHT=S6g9i8f_5DdA7jUjwm1girFxYVhA@mail.gmail.com>
 <CANaZ52BydX-xFqLxLxd=heu+i+BfB=bO-dB1duykxW_KR3DZoA@mail.gmail.com>
 <CAB4PkTxKNZLxFkgtX-UsOrERha_CKp4oqMBF_fPKcfX2JAdOKQ@mail.gmail.com>
 <CAOcnVr3KzYqvJjdQUdRq793ep9U3SAf1P=+ezg6__Sz_S7sVUg@mail.gmail.com>
 <CA+4kjVt1WeR_3nN=d9it8gvpwi2UwM+Qd7D-CP+SO0ddzDAKtA@mail.gmail.com>
 <CAOcnVr09vGV41nMqnpLHVcM9z84kw3AnsBotqP_S=RUxPyKRUQ@mail.gmail.com>
 <CAB4PkTwy+ueMn4vzAi-FBdJaPwdDUkRzsUxVThLepWs7g8Gtbg@mail.gmail.com>
From: Harsh J <harsh@cloudera.com>
Date: Fri, 14 Sep 2012 09:58:07 +0530
Message-ID: 
 <CAOcnVr05D1oH8tFKV2XA4+6xdwTvnk1sGcYWUHNnqc-Oc-BwYQ@mail.gmail.com>
Subject: Re: rack topology data update
To: Jameson Li <hovlj.ei@gmail.com>
Cc: user@hadoop.apache.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Jameson,

Yes unfortunately this is the current case.

On Fri, Sep 14, 2012 at 8:58 AM, Jameson Li <hovlj.ei@gmail.com> wrote:
> Harsh J,
>
> If a new datanode has joined the cluster, and has a default rack info cac=
hed
> in the namenode, it will no way to change its cache other than restart th=
e
> namenode.
> Am I right?
>
> =E4=B8=93=E6=B3=A8=E4=BA=8EMysql,MSSQL,Oracle,Hadoop
>
>
>
> 2012/9/13 Harsh J <harsh@cloudera.com>
>>
>> Hey Steve,
>>
>> True about the decisions part, that still needs the ugly fixing of
>> re-replication.
>>
>> I think I saw it on a JIRA by Patrick A. that was trying to change the
>> way we did this. But placement is also pluggable in 2.x right? Let me
>> find that JIRA (but yeah, am unsure if it was committed).
>>
>> On Thu, Sep 13, 2012 at 2:40 PM, Steve Loughran <stevel@hortonworks.com>
>> wrote:
>> >
>> >
>> > On 13 September 2012 09:03, Harsh J <harsh@cloudera.com> wrote:
>> >>
>> >>
>> >> This should be fixed in one of the 2.x releases, where we also refres=
h
>> >> the cached values.
>> >>
>> >
>> > Really? Which JIRA?
>> >
>> > I've been making changes to the topology logic so you can do some
>> > preflight
>> > checking and dump the topologies, but didn't think a clear and reload
>> > was in
>> > there. Some decisions on block placement strategy (flat vs hierarchica=
l)
>> > are
>> > made early on, so going from flat to multi-switch is not something I'd
>> > recommend.
>>
>>
>>
>> --
>> Harsh J
>
>


--=20
Harsh J