[sheepdog] [PATCH v2 1/2] sheep, dog: make recycling VID selectable

[Hitoshi Mitake]

At Tue, 17 Mar 2015 10:03:53 +0800,
Liu Yuan wrote:
> 
> On Tue, Mar 17, 2015 at 04:44:46AM +0900, MORITA Kazutaka wrote:
> > At Mon, 16 Mar 2015 21:13:29 +0800,
> > Liu Yuan wrote:
> > > 
> > > How about make 'dog vdi clone --no-share' as the default clone operation? And
> > > we can add dog vdi clone --share to keep old behavior as optional. By this
> > > manner, --no-share will save us from this kind of subtle problem. And your team
> > > problem about vdi exhaustion will be achieved :).
> > 
> > --no-share option disables thin provisioing.  It shouldn't be a default option,
> > IMHO.
> 
> Following bug will disable vid recycle for old algorithm.
> 
> commit 21549a1bd4981fabcc09d062a647162127fe0637
> Author: Hitoshi Mitake <mitake.hitoshi at gmail.com>
> Date:   Sun Jun 1 23:23:18 2014 +0900
> 
>     sheep: don't recycle VDI ID
>     
>     Recycling VDI IDs of deleted VDIs is a completely wrong idea. It
>     breaks relations between inode objects and data objects. For example,
>     it can cause a problem of corrupting cloned VDIs (see related
>     issue). This patch forbids the recycling.
>     
>     Related issue:
>     https://bugs.launchpad.net/sheepdog-project/+bug/1317755
>     
>     Signed-off-by: Hitoshi Mitake <mitake.hitoshi at lab.ntt.co.jp>
>     Signed-off-by: Liu Yuan <namei.unix at gmail.com>
> 
> This means we don't have vid recycle for old algorithm now because of this
> subtle problem. This is why I suggest set --no-share as default, in order to
> bring this functionality back.

1. clone --no-share is much heavier operation than whole range lookup
of bitmap. It produces read + write request * # replication for every
objects pointed by a parent snapshot. It means we cannot provide fast
cloning. And space consumption will increase explosively.

2. the old recycling doesn't take care about snapshots completely as I
   wrote in my another email (and the issue in the above link of
   launchpad describes).

> 
> > > 
> > > This manner is not perfect, but it will benefit us:
> > > 
> > > 1. stable code base since old algorithm is long tested.
> > 
> > Hitoshi's patch enables the stable algorithm by default.  Isn't it enough?
> 
> I'm afraid not.
> 
> 1. as above mentioned, simply disable new algorithm won't bring us back vid
>    recycle. But if we bring it back, seems it will conflict with new
>    algorithm.

Revive the old algorithm is completely impossible as I described in the above.

> 2. new algorithm has a bug that need to hack vdi_lookup(), which will degrade it
>    a lot. I'm not sure if we can hack vdi_lookup() to meet two
>    algorithm's needs.

Looking up whole range unconditionally solves the problem. And it can
be disabled with the option if users don't like.

Thanks,
Hitoshi

> 
> > > 2. we won't degrate vdi_lookup
> > 
> > I'm still not sure which code in vdi_lookup() is a problem.  The problem
> > happens even when we disable VID garbage collection?
> 
> vdi_lookup() becomes a problem if Hitoshi's patch is enabled after he fixes a
> fatal bug of new algorithm.
> 
> Thanks,
> Yuan