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 <[email protected]> > 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 <[email protected]> > Signed-off-by: Liu Yuan <[email protected]> > > 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 -- sheepdog mailing list [email protected] https://lists.wpkg.org/mailman/listinfo/sheepdog
