Open Stack

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?