Even though we can create explicit storage levels with different
replication, the stock impl has only two : no and one.
Spark codebase relies on this implicitly.

We had sort of discussed it in the checkpoint to blocks jira (forgot jira
id and can't search right now)
On 27-May-2014 10:39 am, "Aaron Davidson" <notifications@github.com> wrote:

> In core/src/main/scala/org/apache/spark/storage/BlockManager.scala:
>
> > @@ -772,7 +772,7 @@ private[spark] class BlockManager(
> >    /**
> >     * Replicate block to another node.
> >     */
> > -  var cachedPeers: Seq[BlockManagerId] = null
> > +  @volatile var cachedPeers: Seq[BlockManagerId] = null
>
> @rxin <https://github.com/rxin> Looking at this code, is this right? When
> we create this (5 lines down), we seem to give it a specific
> level.replication, so we'll only end up with a certain number of peers,
> which we will then *cache*. It seems to me that every block thereafter
> will be forcibly stored at the same replication level as the first.
>
> This bug may be possible, because it would only show up if you're using 2
> separate replication levels above 1, which is probably uncommon. Am I
> missing something, though?
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/apache/spark/pull/887/files#r13062338>
> .
>