[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