-
Nils Goroll authored
I believe the actual issue reported in #22 is that, with the old disk region allocation scheme, we could need one more disk segment list, such that FCO_REGIONS_RESERVE was too small. But pondering this issue, I went back to square one and re-thought the allocation plan. I now think that there were some fundamental flaws in the previous allocation code: - we did not plan for how many segment lists we would actually need - we would cram the segment allocation, which could lead to the number of segment lists growing - for growing allocations, we would switch from "assume we have enough regions" to "assume we have no regions at all any more" when FCO_REGIONS_RESERVE was reached. Hopefully, this new allocation plan code now takes a more sensible, holistic approach: Whenever we need more disk space (= another disk region), we calculate how many regions we are sensibly going to need in total. For no cram, this is just one, and for abs(cram) >=1 it is going to be the number of one-bits (popcount) of the size. Then we calculate the chunk size which we need to go to in order to fit all segments into segment lists. Based on this outcome, we calculate a maximum cam which we can allow for region allocations. This approach is fundamentally different to before in that we no longer cram segment sizes - which was wrong, because we do not have an infinite number of segment lists. Fixes #22 for real now, I hope