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

Re: Choice of min_free_size

On Wed, 16 Aug 2000, David Woodhouse wrote:
> > R = total amount of obsolete data 
> We don't currently keep track of that, do we? fmc->dirty_size is the total
> size on the flash of the nodes which are completely obsoleted - it doesn't
> count nodes which have been partially obsoleted.

A partially obsoleted node will need to be counted in R as the amount of
obsoleted memory minus the required extra header info of course.

If you have a node with sizeof(header) + data from 0 to 1000, then another
node with sizeof(header) + data from 400 to 600, those nodes together have
an R of 200 (the Rdata) + an extra sizeof(header) because the later node
is in the middle of an existing, so in worst case you need to split into

This is probably the same as your "keep an extra sizeof(header) in case"
but more robust I think.

Would that work ?

> I'm not convinced of that.
> If, for example, you have sector_size 128KB, and you have three dirty 
> blocks each of 50KB, you cannot fit those into a single sector - you have 
> to fragment one of them, which means you're taking an extra 80 bytes for 
> the extra jffs_raw_inode.

What is a "dirty block" ? Do you mean live data ? Where are those 3 dirty
blocks ? Obviously not in a single sector since 50 * 3 > SS. 

You can always copy a sectors worth of nodes into a free sector, and you
can always know that the resulting sector will have the same amount of
live data but less amount of obsolete data. 

> include in R the nodes which are partially obsoleted. The potential for 
> needing an unknown number of extra jffs_raw_inode headers concerns me.

See above. The number is not unknown, merely rounded upwards by an amount
that is perhaps not optimal but guaranteed to work..