On Mon, Mar 21, 2011 at 3:05 PM, Anthony Liguori <aligu...@us.ibm.com> wrote: > 2) The daemon maintains metadata for each image that includes an extent > mapping and then a clustered allocated bitmap within each extent (similar to > FVD).
s/clustered allocated bitmap/cluster allocation bitmap/ ? > 3) All writes result in a sha1 being calculated before the write is > completed. The daemon maintains a mapping of sha1's -> clusters. A single > sha1 may map to many clusters. The sha1 mapping can be made eventually > consistent using a journal or even dirty bitmap. It can be partially > rebuilt easily. Can you explain this in more detail? A write to a single sector of a cluster causes what to happen? Why is the hash calculated before acking the write and not queued in the background if the hash mapping is only eventually consistent? For v3: 1. Snapshots. 2. You can connect remote daemons for read-only master images. If an image is backed off a remote image, reads to unallocated clusters are sent to the remote. This also allows for a master image daemon to keep refcounts of how many instances are currently based of an image, and if they copy/stream that data they can drop instances and storage administrators know the master image is safe for deletion. Stefan
