I think the deletion_work_list you mentioned is to keep the deletion work <div>runs sequentially, we can queue the next work from the list only after the </div><div>previous one finishes.</div><div><br></div><div>thanks,</div>
<div><br></div><div>levin </div><br>On Friday, May 4, 2012, Christoph Hellwig  wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, May 04, 2012 at 10:26:36AM +0800, levin li wrote:<br>

> Creating a work queue seems a good idea, or maybe we can reuse<br>
> the current deletion_queue, I'd try this, since it's more<br>
> acceptable than change the thread model.<br>
<br>
<br>
Btw, why is the current deletion work queue so complicated?  The sheepdog<br>
workqueues look fiarly similar to the Linux kernel ones where you queue up<br>
each item individually, but the delete queue keeps an additional list of<br>
items to be deleted.  What's the reason for that?<br>
</blockquote><br><br>-- <br><font color="#999999">levin</font><div><a href="http://basiccoder.com" style="background-color:rgb(255,255,255)" target="_blank"><font color="#999999">basiccoder.com</font></a></div><br>