[rodionos]

> RAMCloud replicates all data on nonvolatile secondary storage such as disk or flash, so no data is lost if servers crash or the power fails

If I have a write-heavy application, for instance a time-series database, does it mean that eventually I'm going to consume all the RAM, then page cache, and eventually my throughput is going to be disk IO bound?

[arthursilva]

Secondary store is more like a backup, not for spilling.

[rodionos]

Naming aside, is the write throughput into the RAMCloud constrained by the cumulative disk IO write speed? If my sustained write speed is greater than total disk throughput, I either have to drop writes or slow down producers, correct?

[jo909]

Usually yes, that is a limit you would mostly not want to exceed. It would slow down producers (not ack newer writes until older backup copies are flushed to disk).

The backup copies of the data is stored on a configurable amout of _other_ systems in the cluster. They receive it to memory, and then the write is acked to the client. Then the backup is written asyncronous to disk on those systems.

You could configure that backups are not written to disk at all, if you have so much memory in the cluster (and do not care for that additional level of durability). Or the size of the buffer of unflushed data which would cover some longer write spikes.

The point is more that the backup copies become "free" once they are written to disk. Otherwise the cluster could only store 25% of it's memory size if you want 3 backup copies.

[arthursilva]

I'm not 100% familiar with the internals, but I think it's safe to say that the persistence part is asynchronous in order to reach the low latency goals of the system.