[sheepdog] [PATCH v3 3/3] sheep: look up whole range of bitmap

[Hitoshi Mitake]

Older sheepdog didn't have a functionality of recycling VID, so the
get_vdi_bitmap_range() can detect correct range of bitmap. But newer
sheepdog recycles VID. It can produce situations like below:

The first state of VID bitmap:
0 0 1* 1* 1 0 0 0
1 is a VID bit of working VDI, 1* is a bit of snapshot. Assume the
above 1 and 1* are used for VDI named "A" and its snapshots.

Then, a user tries to create VDI "B". sd_hash_vdi() returns VID which
conflicts with existing bits for A.
0 0 1* 1* 1 0 0 0
       ^
       |
       sd_hash_vdi() returns VID which conflicts with the
       above bit.

So B acquires the left most free bit
0 0 1* 1* 1 1 0 0
            ^
            |
            B acquires this bit.

Then, the user deletes A and its snapshots. All of the family members
are deleted. The bitmap becomes like below
0 0 0 0 0 1 0 0
      ^
      |
      B's original VID sd_hash_vdi() calculates.

Now sheep fails to lookup VID of B, because the VID calculated by
sd_hash_vdi() is zero.

This is the reason of the looking up whole range of bitmap. Of course
it is ugly and costly. But its cost is equal or less than "dog vdi
list"'s one.

Signed-off-by: Hitoshi Mitake <mitake.hitoshi at lab.ntt.co.jp>
---
 sheep/vdi.c | 45 +++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 45 insertions(+)

v3:
 - handle a case of recycled VID problem for lookup

diff --git a/sheep/vdi.c b/sheep/vdi.c
index fbb4534..bb6a170 100644
--- a/sheep/vdi.c
+++ b/sheep/vdi.c
@@ -1496,6 +1496,51 @@ int vdi_lookup(const struct vdi_iocb *iocb, struct vdi_info *info)
 	sd_debug("%s left %lx right %lx, %x", iocb->name, left, right, ret);
 	switch (ret) {
 	case SD_RES_NO_VDI:
+		/*
+		 * Why is the below heavy fill_vdi_info() required?
+		 *
+		 * Older sheepdog didn't have a functionality of recycling VID,
+		 * so the above get_vdi_bitmap_range() can detect correct range
+		 * of bitmap.
+		 *
+		 * But newer sheepdog (1.0 <=) recycles VID. It can produce
+		 * situations like below:
+		 *
+		 * The first state of VID bitmap:
+		 * 0 0 1* 1* 1 0 0 0
+		 * 1 is a VID bit of working VDI, 1* is a bit of snapshot.
+		 * Assume the above 1 and 1* are used for VDI named "A" and
+		 * its snapshots.
+		 *
+		 * Then, a user tries to create VDI "B". sd_hash_vdi() returns
+		 * VID which conflicts with existing bits for A.
+		 * 0 0 1* 1* 1 0 0 0
+		 *        ^
+		 *        |
+		 *        sd_hash_vdi() returns VID which conflicts with the
+		 *        above bit.
+		 *
+		 * So B acquires the left most free bit
+		 * 0 0 1* 1* 1 1 0 0
+		 *             ^
+		 *             |
+		 *             B acquires this bit.
+		 *
+		 * Then, the user deletes A and its snapshots. All of the family
+		 * members are deleted. The bitmap becomes like below
+		 * 0 0 0 0 0 1 0 0
+		 *       ^
+		 *       |
+		 *       B's original VID sd_hash_vdi() calculates.
+		 *
+		 * Now sheep fails to lookup VID of B, because the VID
+		 * calculated by sd_hash_vdi().
+		 *
+		 * This is the reason of the below fill_vdi_info(). Of course it
+		 * is ugly and costly. But its cost is equal or less than
+		 * "dog vdi list"'s one.
+		 */
+		return fill_vdi_info(1, SD_NR_VDIS - 1, iocb, info);
 	case SD_RES_FULL_VDI:
 		return ret;
 	case SD_RES_SUCCESS:
-- 
1.9.1