Open Stack

On Mon, 2 May 2011 21:11:22 -0400
Eric Windisch <eric at cloudscaling.com> wrote:

> I expect there will be great demand for an implementation of a Swift
> as a block device client.  Care should be made in deciding what will

Surely. I also modified tgt to simply store data on Swift. It doesn't
work well due to Swift's week consistency.

To implement a block device on the top of Swift, you need to sorta a
log structure file system, that is, never over-write the existing
objects. Updating the data means creating new objects.


>> As I wrote in the previous mail, the tricky part of the dm-snapshot
>> approach is getting the delta of snaphosts (I assume that we want to
>> store only deltas on Swift). dm-snapshot doesn't provide the
>> user-space API to get the deltas. So Lunr needs to access to
>> dm-snapshot volume directly. It's sorta backdoor approach (getting the
>> information that Linux kernel doesn't provide to user space). As a
>> Linux kernel developer, I would like to shout at people who do such :)
> 
> With dm-snapshot, the solution is to look at the device mapper table
> (via the device mapper API) and access the backend volume. I don't
> see why this is a bad solution. In fact, conside

Hmm, seems that we aren't on the same page.

I'm talking about how to get an incremental changes from the original
volume. They are stored in the exception table in dm-snapshot. IIRC,
the information doesn't exported to user space.