Open Stack

We have no current plans to make an iSCSI target for swift.  Not only would
there be performance issues, but also consistency issues among other things.
 For Lunr, swift will only be a target for backups from block devices.

I think some of this confusion stems from the confusion around snapshots,
and Fujita's proposal would make an interesting case if we were going to use
swift for more traditional snapshots.  But since we are looking to use swift
as backups for volumes, we will not need that type of functionality
initially.

Eric:  Our current snapshot prototype uses FUSE since that is very simple to
do in python, but we are also considering using a NBD (among other options).
 Once we have this nailed down a bit more, we will send out more details.

--
Chuck

On Mon, May 2, 2011 at 8:29 PM, Nelson Nahum <nelson at zadarastorage.com>wrote:

> Is Swift as a Block device a real option? It looks to me that
> performance will be a big problem. Also how the three copies of Swift
> will be presented as iSCSI?  Only one? Each one with its own iSCSI
> target? Who serialize the writes in this scenario?
>
> Nelson
>
> On Mon, May 2, 2011 at 6:11 PM, Eric Windisch <eric at cloudscaling.com>
> wrote:
> >
> >> 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 at cloudscaling.com
> >
> >
> >
> >
> > _______________________________________________
> > Mailing list: https://launchpad.net/~openstack
> > Post to     : openstack at lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~openstack
> > More help   : https://help.launchpad.net/ListHelp
> >
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20110502/09f37186/attachment.html>