openstack team mailing list archive

[FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx>]

On Mon, 2 May 2011 15:45:20 -0400
Eric Windisch <eric@xxxxxxxxxxxxxxxx> wrote:

> You're involved in the tgt project and it is the tgt project's
> purgative to add features as seen fit, but are you sure that you
> want to support this feature?

I'm the maintainer so I can add anything useful unless I upset the
existing users. Swift support can be implemented as one of tgt I/O
drivers so it's unlikely that the addition can hurt the existing code.


> I can see the advantages of having Swift support in tgt; However, is
> considerably complex.  You're mapping a file-backed block device on
> a remote filesystem to a remote block storage protocol (iSCSI).
> Might it not be better, albeit less integrated, to improve the Swift
> FUSE driver and use a standard loopback device?  This loopback
> device would be supported by the existing AIO driver in tgt.

The implementation of the snapshot itself is complicated but
integrating it into tgt isn't so complicated to me. tgt already
supports things complicated than a file-backed block device. For
example, it uses the own image format for the virtual tape library
feature. It also support sending SCSI commands via sg char devices.

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


> I foresee that Lunr could use dm-snapshot to facilitate backups
> and/or to provide a COW against dm-zero for the purpose of
> preventing information disclosure.

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 :)