Arvados

• keep0 mounts vol0 (rw), vol1 (ro)
• keep1 mounts vol1 (rw), vol0 (ro)
• keep2 mounts vol2 (rw), vol3 (ro)
• keep3 mounts vol3 (rw), vol2 (ro)

This setup is desirable when each block appears on only one backend volume, i.e., when the desired replication level is already provided by the backend. When a single keep server goes down, all blocks are still readable.

However, with this setup, the current keep-balance implementation will never move a block to a better rendezvous position. It sees N readonly replicas and figures there's no point making more copies on different servers: it won't be able to delete the readonly replicas, so making more replicas will result in permanent overreplication. If it pays attention to the device IDs reported by the servers, it could understand that the readonly replicas are just different views of writable replicas it sees elsewhere, and ignore them.