...
- Another approach to checkpointing: full pages
- Use a relatively small "page" size (1024 bytes?)
- During updates, send entire pages to backup servers
- Backup servers must coalesce these updated pages into larger units for transfer to disk
- The additional overhead for sending entire pages during commit may make this approach impractical
- Yet another approach to checkpointing:
- Server sends operation log to backups.
- It's up to backups to figure out how to persist this: they must generate
a complete enough disk image so that they can quickly regenerate all of the
data they have ever received. No explicit checkpoint data is sent to backups. - During recovery the backup can provide the recovered data in any order (it can always be rearranged in memory).
- This starts sounding a lot like a log-structured file system.
...
- Could the operation log also serve as an undo/redo log and audit trail?
- What happens if there is an additional crash during recovery?
- What level of replication is required for RAMCloud to be widely accepted? Most likely, single-level redundancy will not be enough.
- The approach to persistence may depend on the data model. For example,
if there are indexes, will they require different techniques for persistence
than data objects?