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 hovlj.ei@gmail.com designates
 209.85.214.176 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAOcnVr09vGV41nMqnpLHVcM9z84kw3AnsBotqP_S=RUxPyKRUQ@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>
From: Jameson Li <hovlj.ei@gmail.com>
Date: Fri, 14 Sep 2012 11:28:26 +0800
Message-ID: 
 <CAB4PkTwy+ueMn4vzAi-FBdJaPwdDUkRzsUxVThLepWs7g8Gtbg@mail.gmail.com>
Subject: Re: rack topology data update
To: user@hadoop.apache.org
Cc: harsh <harsh@cloudera.com>
Content-Type: multipart/alternative; boundary=e89a8ff1c7e02ec02a04c9a1061c

--e89a8ff1c7e02ec02a04c9a1061c
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Harsh J,

If a new datanode has joined the cluster, and has a default rack info
cached in the namenode, it will no way to change its cache other than
restart the 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 refresh
> >> 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 hierarchical=
)
> are
> > made early on, so going from flat to multi-switch is not something I'd
> > recommend.
>
>
>
> --
> Harsh J
>

--e89a8ff1c7e02ec02a04c9a1061c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><span style=3D"color:rgb(34,34,34);font-family:arial,sans-=
serif;font-size:14px;font-weight:bold;text-align:left;white-space:nowrap;ba=
ckground-color:rgb(255,255,255)">Harsh J,</span><br clear=3D"all"><br>If a =
new datanode has joined the cluster, and has a default rack info cached in =
the namenode, it will no way to change its cache other than restart the nam=
enode.<div>

Am I right?<br><div><br></div><div>=E4=B8=93=E6=B3=A8=E4=BA=8EMysql,MSSQL,O=
racle,Hadoop<br>
<br><br><div class=3D"gmail_quote">2012/9/13 Harsh J <span dir=3D"ltr">&lt;=
<a href=3D"mailto:harsh@cloudera.com" target=3D"_blank">harsh@cloudera.com<=
/a>&gt;</span><br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex">

Hey Steve,<br>
<br>
True about the decisions part, that still needs the ugly fixing of<br>
re-replication.<br>
<br>
I think I saw it on a JIRA by Patrick A. that was trying to change the<br>
way we did this. But placement is also pluggable in 2.x right? Let me<br>
find that JIRA (but yeah, am unsure if it was committed).<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
On Thu, Sep 13, 2012 at 2:40 PM, Steve Loughran &lt;<a href=3D"mailto:steve=
l@hortonworks.com">stevel@hortonworks.com</a>&gt; wrote:<br>
&gt;<br>
&gt;<br>
&gt; On 13 September 2012 09:03, Harsh J &lt;<a href=3D"mailto:harsh@cloude=
ra.com">harsh@cloudera.com</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; This should be fixed in one of the 2.x releases, where we also ref=
resh<br>
&gt;&gt; the cached values.<br>
&gt;&gt;<br>
&gt;<br>
&gt; Really? Which JIRA?<br>
&gt;<br>
&gt; I&#39;ve been making changes to the topology logic so you can do some =
preflight<br>
&gt; checking and dump the topologies, but didn&#39;t think a clear and rel=
oad was in<br>
&gt; there. Some decisions on block placement strategy (flat vs hierarchica=
l) are<br>
&gt; made early on, so going from flat to multi-switch is not something I&#=
39;d<br>
&gt; recommend.<br>
<br>
<br>
<br>
</div></div><span class=3D"HOEnZb"><font color=3D"#888888">--<br>
Harsh J<br>
</font></span></blockquote></div><br></div></div></div>

--e89a8ff1c7e02ec02a04c9a1061c--