[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Choice of min_free_size
> 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.