Sam Johnston <samj@samj.net> writes:
For example I should be able to rsync the raw block device of a physical server to the cloud
Off-topic: rsyncing giant files/block devices does reduce network traffic, but it involves an end-to-end read at both ends as well as any writes. The thing which is most painfully constrained for cloud infrastructure providers is disk IO, especially with traditional hard drives with long seek times, so we're unlikely to provide such an interface for fear of encouraging its use! rsyncing the contents of filesystems within block devices is far, far more friendly to shared storage, because by default files are skipped completely on the basis of size and mtime.
Sure, snapshot's easy... you just have a "snapshot" actuator which returns a new resource (complete with a pointer to the "live" version).
Snapshots are easy if we're starting from scratch and are allowed to define their semantics, for instance a snapshot operation on a drive gives a new drive with copy-on-write behaviour between them. The problem comes when you want to retrofit this to (say) Amazon EBS, where snapshots are second class objects, which can be generated from and imaged to a block device, but are not a block device in themselves. If, on the other hand, you treat snapshots as a distinct type of object, functionality is lost from the interfaces of people who currently implement them better, so they do appear exactly like on-demand clones of drives. Cheers, Chris.