[sheepdog] [PATCH v3 0/9] object reclaim based on generational reference counting

[Liu Yuan]

On Mon, Feb 24, 2014 at 05:52:28PM +0900, MORITA Kazutaka wrote:
> At Mon, 24 Feb 2014 11:08:28 +0800,
> Liu Yuan wrote:
> > 
> > On Sun, Feb 23, 2014 at 07:08:27PM +0900, Hitoshi Mitake wrote:
> > > On Sun, Feb 23, 2014 at 2:28 PM, Hitoshi Mitake
> > > <mitake.hitoshi at gmail.com> wrote:
> > > > The object reclaim doesn't support hypervolume yet. But hypervolume cannot be
> > > > used as a virtual disk (both of qemu and tgt don't support it) currently. And
> > > > the removal of old vdi deletion is acceptable for hypervolume because it doesn't
> > > > support snapshot, etc. So I think this patchset can be applied to the master
> > > > branch.
> > > >
> > 
> > I don't think we should merge this patch set in such a haste because it is in
> > the critical deletion patch that is unlike conditional feature, e.g, nfs, http
> > that if not enabled, users won't be affected. There are some uers like us using
> > master branch as the production base. I think of marking the master tip as 
> > stable-0.8.1 before applying this patch set.
> 
> What do you mean?  I think 0.8.1 should be marked in the stable-0.8
> branch.  I really don't think using a master branch for production is
> a good idea.

We want use some features like multi-threaded recovery which is not in the
stable-0.8 and other works in http. These works might not be suitable to
backport to stable-0.8. So we have to use code base on master tip (or some 
commit).

But the conflcit is that new reclaim algorithm won't be stable soon so we can't
choose a commit after reclaim is merged. (We will choose one commit in the
master before April as our internally maintained code base or probably we can
make use of stable-0.8 if it hopefully matches our needes).

> 
> I'd suggest that this series be merged at the early stage.  This
> change is very fundamental one, so I and Hitoshi had spent a lot of
> time for rebasing to master every time.  If we want to see this
> feature in the next release, we should move to incremental development
> as soon as possible after adding more tests and addressing our
> reviews.

Sure, we also want it to be stable as soon as possible because our cluster is
heavily relying on the snapshots and clones.

Thanks
Yuan