Re: Choice of min_free_size

[David Woodhouse <dwmw2@xxxxxxx.org>]

dwmw2@xxxxxxx.com said:
>  The arithmetic I posted seems to help, as a first attempt - i.e.
> don't  write a larger node than the one we're obsoleting if there's
> not enough  free space to copy all the other nodes in the tail. 

That wasn't enough. I've also modified JFFS_ENOUGH_SPACE to take an extra 
argument - the amount of space required. Then it returns 'OK' if there'll 
be min_free_size bytes available _after_ the allocation, rather than its 
previous behaviour of returning success if there are min_free_bytes 
available _before_ the allocation.

Beforehand, the free_size could go as low as min_free_size - 
max_chunk_size, which wasn't enough for the GC to continue. 

My tests have been running for a while now - longer than I remember it 
taking to fall over last night. It looks better - Sod's Law says it'll fall 
over as soon as I hit 'send' though :)

I would _really_ like to see a mathematical proof that the GC can't kill 
itself like this, and that there'll always be room to delete files.

--
dwmw2