openstack team mailing list archive

[Eric Windisch <eric@xxxxxxxxxxxxxxxx>]

> Surely, FUSE is another possible option, I think. I heard that lunr
> team was thinking about the approach too.

I'm concerned about the performance/stability of FUSE, but I'm not sure if using iSCSI is a significantly better option when the access is likely to be local. If I had to choose something in-between, I'd evaluate if NBD was any better of a solution. 

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 be the best-supported method/implementation. That said, you have an implementation, and that goes a long way versus the alternatives which don't currently exist.


> 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, considering that the device mapper table could be arbitrarily complex and some backend volumes might be entirely virtual, i.e. dm-zero, this seems fairly reasonable to me.

I really don't see at all how Swift-as-block-device relates at all to (storage) snapshots, other than the fact that this makes it possible to use Swift with dm-snapshot.

Regards,
Eric Windisch
eric@xxxxxxxxxxxxxxxx