<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">2014/1/8 MORITA Kazutaka <span dir="ltr"><<a href="mailto:morita.kazutaka@gmail.com" target="_blank">morita.kazutaka@gmail.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">At Mon, 6 Jan 2014 17:16:22 +0800,<br>
<div><div class="h5">Robin Dong wrote:<br>
><br>
> Hi All,<br>
><br>
> At present, the implemention of swift interface for creating object in<br>
> sheepdog is:<br>
><br>
> 1. lock container<br>
> 2. check whether the onode with same object name is exists.<br>
> 3. unlock container<br>
> 4. upload object<br>
> 5. create onode<br>
><br>
> this sequence have a problem: if two clients uploading same objects<br>
> concurrently, it will create two<br>
> objects with same names in container.To avoid duplicated names, we must put<br>
> "create onode"<br>
> operation in container lock regions.<br>
><br>
> Therefore we need to change the processes of creating object to:<br>
><br>
> 1. lock container<br>
> 2. check whether the onode is exists.<br>
> 3. allocate data space for object, and create onode, then write it done<br>
> 4. unlock container<br>
> 5. upload object<br>
><br>
> this routine will avoid uploading duplicated objects.<br>
><br>
> There is an exception on the new routine: if the client halt the uploading<br>
> progress, we will have a<br>
> "uploading uncompleted" onode.<br>
> I think this problem is easy to solve: we can add code for onode to<br>
> identify its status.<br>
> A new onode will be set to "INIT", and after uploading completed, the onode<br>
> will be set to  "COMPLETED".<br>
<br>
</div></div>Then, the procedure will be as follows?<br>
<div class="im"><br>
  1. lock container<br>
  2. check whether the onode is exists.<br>
  3. allocate data space for object, and create onode, then write it done<br>
</div>  4. mark the onode as "INIT"<br>
  5. unlock container<br>
  6. upload object<br>
  7. mark the onode as "COMPLETED"<br>
<br>
I'm not against this suggestion, but I'm wondering whether we can get<br>
enough performance with this approach.  IIUC, this introduces<br>
additional write requests to the created onode at 7.<br></blockquote><div><br></div><div>Hi  MORITA,</div><div><br></div><div>We may only write the status (may be a "uint_8" type) of onode back at 7. So</div><div>
the performance will not be hurted too much.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<br>
I've been evaluating Swift these days and noticed that Swift can<br>
process thousands of PUT requests per second with only 3 nodes and 100<br>
disks.  Can Sheepdog achieve similar or better performance with the<br>
suggestion?<br></blockquote><div> </div><div>At present, the bottleneck of swift on sheepdog is the distributed-lock on each container.</div><div>Therefore if we send PUT requests on different one hundred containers, I think sheepdog could</div>
<div>achieve the similar performance with the suggestion.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<br>
Thanks,<br>
<br>
Kazutaka<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>--<br>Best Regard<br>Robin Dong
</div></div>