Hello, Chuck told me at the conference that lunr team are still working on the reference iSCSI target driver design and a possible design might exploit device mapper snapshot feature.
I think that the advantage of the dm design is that you don't need to invent lots about snapshot feature and the disadvantages is that the dm doesn't provide the interface for user space to get the delta between snapshots so you need to directly access to the dm snapshot disk format. You also need to invent something to enable VMs to boot from snapshot saved on Swift instantly (that is, without downloading all the volume data from Swift). I think that the dm desing would work but I also liked to see how a different design works and I played during my boring flight time to Japan. You can get the code at: git://git.kernel.org/pub/scm/linux/kernel/git/tomo/tgt.git snap2swift I modified the iSCSI target daemon to use Swift and local storage. When you create new volume on Swift, a new container is created and the volume image is split into multiple fixed-size objects (8MB for now), which are stored in the container. That is, the first 16 sector (512 bytes) data are saved into the first object, and so on. A VM can boot from the volume on Swift instantly because the iSCSI target daemon directly gets the volume data from Swift (without downloading all the objects locally). When the VM sends a WRITE request (that is, updating a disk sector), the iSCSI target daemon stores the modified objects locally (the volume objects on Swift are never modified). The iSCSI target daemon use both of the objects on Swift and local modified objects to give the latest volume data to the VM. When an user creates a new snapshot, the iSCSI target daemon stores the modified objects stored locally to Swift. They are stored as version one. The daemon also stores the snapshot description object. It's just a table which describes the latest object version. For example, if the first 16 sectors are not modified from the initial volume creation, the first table entry (for the first object) is zero. If modified, the first table entry is one. If the user creates another snapshot, some second version objects are stored on Swift. The entries of the second version description object could be zero, one, or two. So you store only deltas on Swift. Well, I've not implemented the snapshot creation feature. But you can create new volume on Swift (by cloning the existing disk image file) and enables a VM to read/write it (as described above, the modified objects are stored locally). I've not tested the code much but seems to work. doc/README.swap2swift describes how to set up the iSCSI target daemon. Opinions? _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
