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.<div>
<br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>--</div><div>Chuck<br><div><br><div class="gmail_quote">On Mon, May 2, 2011 at 8:29 PM, Nelson Nahum <span dir="ltr"><<a href="mailto:nelson@zadarastorage.com">nelson@zadarastorage.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Is Swift as a Block device a real option? It looks to me that<br>
performance will be a big problem. Also how the three copies of Swift<br>
will be presented as iSCSI?  Only one? Each one with its own iSCSI<br>
target? Who serialize the writes in this scenario?<br>
<font color="#888888"><br>
Nelson<br>
</font><div><div></div><div class="h5"><br>
On Mon, May 2, 2011 at 6:11 PM, Eric Windisch <<a href="mailto:eric@cloudscaling.com">eric@cloudscaling.com</a>> wrote:<br>
><br>
>> Surely, FUSE is another possible option, I think. I heard that lunr<br>
>> team was thinking about the approach too.<br>
><br>
> 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.<br>

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

><br>
><br>
>> As I wrote in the previous mail, the tricky part of the dm-snapshot<br>
>> approach is getting the delta of snaphosts (I assume that we want to<br>
>> store only deltas on Swift). dm-snapshot doesn't provide the<br>
>> user-space API to get the deltas. So Lunr needs to access to<br>
>> dm-snapshot volume directly. It's sorta backdoor approach (getting the<br>
>> information that Linux kernel doesn't provide to user space). As a<br>
>> Linux kernel developer, I would like to shout at people who do such :)<br>
><br>
><br>
> 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.<br>

><br>
> 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.<br>
><br>
> Regards,<br>
> Eric Windisch<br>
> <a href="mailto:eric@cloudscaling.com">eric@cloudscaling.com</a><br>
><br>
><br>
><br>
><br>
> _______________________________________________<br>
> Mailing list: <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
> Post to     : <a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>
> Unsubscribe : <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
> More help   : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><br>
><br>
<br>
_______________________________________________<br>
Mailing list: <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
Post to     : <a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>
Unsubscribe : <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
More help   : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><br>
</div></div></blockquote></div><br></div></div>