Bug #55573
openstretch mode: be more sane about changing different size/min_size
0%
Description
From the mailing list:
I created 2 aditional pools each with a matching stretch rule:
- size=2/min=1 (not advised I know)
- size=6/min=3 (some kind of paranoid config)
When entering degraded stretch mode, the following changed where made automatically:
- size=4/min=2 > size=4/min=1 size=2/min=1 > size=2/min=0 (!) size=6/min=3 -> size=6/min=1 (!)
Not really sure about what calc is performed here, but:
- It would be better to check not decrement min value below 1?
- Changing min=3 to min=2 would be better (safer)?
Also, when stretch bucket was back online and after recovery was complete:
- size=4/min=2 > size=4/min=1 -> size=4/min=2 size=2/min=1 > size=2/min=0 -> size=2/min=2 size=6/min=3 -> size=6/min=1 -> size=6/min=2
This time it seems recovery is setting min=2 as a fixed value.
Would it make sense that when entering degraded mode, min was set to min(round(size/2)-1, 1); and after recovery it was set to round(size/2)?
=============
Currently, we are just doing min_size/2 (integer arithmetic) and then restoring min_size to a config value mon_stretch_pool_min_size.
When we eventually support arbitrary numbers of stretch buckets, a simple multiply/divide may not work (we'll want options for things like 3 zones, where we maintain a single copy in at least two zones), but the proposed changes seem good for the existing 2-site case.
Updated by Eneko Lacunza about 2 years ago
Realized my suggestion/formula in the mailing list wasn't good :)
This is what I intended originally:
- degraded mode, min_size = max(floor(size/2)-1, 1)
- after recovery, min_size = floor(size/2)
Thanks