[sheepdog] [PATCH 2/2] sheep: cleaning vdi deletion process, round 2
Hitoshi Mitake
mitake.hitoshi at gmail.com
Tue Jan 28 07:26:52 CET 2014
At Tue, 28 Jan 2014 14:13:15 +0800,
Liu Yuan wrote:
>
> On Tue, Jan 28, 2014 at 03:05:18PM +0900, Hitoshi Mitake wrote:
> > At Tue, 28 Jan 2014 12:41:02 +0900,
> > Hitoshi Mitake wrote:
> > >
> > > At Tue, 28 Jan 2014 11:11:49 +0800,
> > > Liu Yuan wrote:
> > > >
> > > > On Tue, Jan 28, 2014 at 11:38:22AM +0900, Hitoshi Mitake wrote:
> > > > > This patch cleans the vdi deletion process of sheep. Current vdi
> > > > > deletion code creates one work for one deletion. It seems that there
> > > > > is no reason to create so many work. This patch lets the code to
> > > > > create only one work for vdi deletion request.
> > > >
> > > > why not? For now our deletion is very slow already, there are cases that
> > > > multiple deletion requests will be issued by users. With your patch, concurrent
> > > > deletions will be plainly slow to users.
> > >
> > > The patch doesn't affect the performance of deletion. Because the
> > > deletion workqueue is an ordered one.
> > >
> > > Quoting from create_work_queues():
> > > sys->deletion_wqueue = create_ordered_work_queue("deletion");
> >
> > In addition, the vdi deletion work produces its successor at the end
> > of its process. Current code doesn't have parallelism. So I think this
> > patch doesn't harm performance.
> >
> > I don't know why current vdi deletion process is doing such a tricky
> > work...
>
> Only Kazutaka knows the reason. I guess it was planned to be paralle. I think
> deletion code is really dirty and tricky and hard to maintain, need refactor and
> redesign.
Of course I agree so I'm writing this patch.
Thanks,
Hitoshi
More information about the sheepdog
mailing list