Skip to content
  • Nils Goroll's avatar
    fellow_cache: Rewrite body layout planning · 9ae6ed10
    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
    9ae6ed10