Open Stack

On May 2, 2011, at 12:50 PM, FUJITA Tomonori wrote:

> 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.


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 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.

To clarify on the subject of snapshots: The naming of snapshots in Nova and their presence on disk is more confusing than it should be. There was some discussion of attempting to clarify the naming conventions.  Storage snapshots as provided by the device mapper are copy-on-write block devices, while Nova will also refer to file-backing stores as snapshots.  This latter definition is also used by EC2, but otherwise unknown and unused in the industry.

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.  Both of these use-cases would be most applicable to local storage, whereas most iSCSI targets would provide these as part of their filer API and it would probably not be very useful at all for Swift.  The only reasons to perform storage-snapshots/COW for iSCSI targets would be for relatively dumb filers that cannot do this internally, or for deployments where their smart filers have edge-cases preventing or breaking the use of these features.

Regards,
Eric Windisch
eric at cloudscaling.com