The decrease in replication is (almost always) temporary until the cluster can copy the blocks in question.
My point was that losing the origination node is no worse or better than losing any other node. Losing a node is bad, but not terribly bad. That the the entire point of distributed file stores like hadoop. On 3/25/08 3:54 PM, "Alfonso Olias Sanz" <[EMAIL PROTECTED]> wrote: > Shouldn't be the a service or a daemon that runs whenever a data node > crashes? This process would be launched by the master. > > The recovery service should check the blocks that have been lost and > replicate them from the rest of the running nodes. Then the > replication level would be guaranteed. > > What happens if the data node goes back and joins the group during the > recovery process. > Or at some point whenever the recovery process has ended. > > Is the developers list the right place to open this discussion? > > Thanks a lot! > > > On 25/03/2008, Ted Dunning <[EMAIL PROTECTED]> wrote: >> >> I hate to point this out, but losing *any* data node will decrease the >> replication of some blocks. >> >> >> >> On 3/24/08 4:53 PM, "lohit" <[EMAIL PROTECTED]> wrote: >> >>>> Improves performance on the basis that files are copied locally in >>>> that node, so there is no need network transmission. But isn't that >>>> policy more weak? If that node crashes ( he worst case), you loses 1 >>>> redundancy level. >>> This policy was for better write performance. As you mentioned, yes in your >>> case you have only 2 copies and it increases the probability of losing >>> replicas. There has been discussion about having different policy for >>> different files, but hasn't been implemented yet. >> >>
