[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Flash space allocation




Let's assume for the moment that we have mathematical proof that the GC can 
operate if we have at least min_free_size bytes available, or at least that 
we're happy with empirical evidence.

I think we want three levels of allocation.

 1. Garbage Collect. Any space it wants, it can have, right up to the
	point where free_size == 0. We have to trust it	not to 
	deadlock itself.

 2. jffs_remove(). In the long term, this will save us space, so
	we let it have space right up to min_free_size, in the
	knowledge that we can GC right after it's finished.

 3. All other writes. These eat space. We therefore don't let them
	eat right up to min_free_size, we leave a little bit of extra
	slack for deletions.


I think part of our problem is that there are races in the 
JFFS_ENOUGH_SPACE() and jffs_fmalloc() code paths which can lead to 
jffs_fmalloc() giving out space to new data which really ought to be 
preserved for GC. 

The interaction between the write lock and the gc lock doesn't help us do 
this nicely.

I'm going to add an extra counter to the jffs_fmcontrol: reserved_size. 

Writers will use this to reserve space on the filesystem before they 
actually obtain any locks or call jffs_fmalloc() to allocate it. They are 
guaranteed that jffs_fmalloc() will succeed if fmc->reserved_size is large 
enough to cover the allocation. 


--
dwmw2