[sheepdog] [PATCH 2/2] sheep: cleaning vdi deletion process, round 2
Hitoshi Mitake
mitake.hitoshi at gmail.com
Wed Jan 29 09:41:23 CET 2014
At Wed, 29 Jan 2014 17:37:24 +0900,
MORITA Kazutaka wrote:
>
> At Tue, 28 Jan 2014 19:30:39 +0900,
> Hitoshi Mitake wrote:
> >
> > At Tue, 28 Jan 2014 17:04:14 +0900,
> > MORITA Kazutaka wrote:
> > >
> > > At Tue, 28 Jan 2014 15:26:52 +0900,
> > > Hitoshi Mitake wrote:
> > > >
> > > > >
> > > > > 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.
> > >
> > > Rather than refactoring the current code, I think we should move to
> > > the new delete implementation based on reference counting for the 0.9
> > > release.
> > >
> > > Hitoshi, you said me before that you would take over my work to
> > > implement an object reclaim feature. It looks better to me to finish
> > > the work first. I guess the object reclaim code will remove this
> > > patch's changes.
> >
> > Yes I'll work on the object reclaim, sorry for pending.
> >
> > But I want to fix current code first because I need to clean up the
> > vdi deletion in stable-0.7 and stable-0.8. It is really hard to
> > maintain. e.g. we faced segfault during stress test of sheepdog and
> > callstack implied the bug is in the vdi deletion process. But it is
> > really difficult for detecting the root cause of the segfault because
> > of the tricky code. I don't want to see similar problems come from the
> > vdi deletion in the future.
> >
> > For long-term maintenance of v0.7.x and v0.8.x, I want to clean up
> > current vdi deletion process first.
>
> Okay, it makes sense to me.
Thanks for your review.
Could you push it to the master, Yuan or Kazutaka-san?
Thanks,
Hitoshi
More information about the sheepdog
mailing list